Currently, there's no way to represent a DST. This causes users of Sway to use low-level escape hatches:

fn main(
  // Variable length args as `(buf_offset, len)`
  arg1: (u64, u64),
  arg2: (u64, u64),
) -> (u64, u64) {
  // Buffer is appened to script_data so it should be
  // right after `arg2`
  let buf_ptr = addr_of(arg2) + size_of_val(arg2);

  // Turn arg offsets into pointers
  arg1.0 += buf_ptr;
  arg2.0 += buf_ptr;

  // Do something with the args
  let res: (u64, u64) = concat(arg1, arg2);

  // Return the result
  asm(ptr: res.0, len: res.1) {
    retd ptr len
  }
}

These low level operations can be extracted from main as such:

struct raw_slice {
  ptr: u64,
  len: u64,
}
impl raw_slice {
  fn ret() -> raw_slice {
    asm(ptr: self.ptr, len: self.len) {
      retd ptr len
    };
    // Make compiler happy
    asm() { zero: raw_slice }
  }
}

struct ScriptDataRawSlice {
  offset: u64,
  len: u64,
}
impl Into<raw_slice> for ScriptDataRawSlice {
  fn into(self) -> raw_slice {
    let buf_ptr = /* ... */;
    raw_slice {
      ptr: buf_ptr + self.offset,
      len: self.len
    }
  }
}

fn main(
  arg1: ScriptDataRawSlice,
  arg2: ScriptDataRawSlice,
) -> raw_slice {
  concat(arg1.into(), arg2.into()).ret()
}

And with the compiler doing all this implicitly, main becomes:

fn main(
  arg1: raw_slice,
  arg2: raw_slice,
) -> raw_slice {
  concat(arg1, arg2)
}

Then we could add typed slices and use it with Vec:

struct slice<T> {
  ptr: u64,
  len: u64, // This isn't in bytes but in Ts
}
impl<T> slice<T> {
  fn byte_len(self) -> u64 {
    self.len * size_of::<T>()
  }
}

impl<T> Into<slice<T>> for Vec<T> {
  fn into(self) -> slice<T> {
    slice {
      ptr: self.buf.ptr,
      len: self.len,
    }
  }
}
impl<T> From<slice<T>> for Vec<T> {
  fn into(self) -> slice<T> {
    Vec {
      buf: RawVec {
        ptr: self.ptr,
        cap: self.len,
      },
      len: self.len,
    }
  }
}

fn main(
  arg1: Into<Vec<u64>>,
  arg2: Into<Vec<u64>>,
) -> Into<slice<u64>> {
  concat(arg1.into(), arg2.into()).into()
}

And with the compiler doing all this implicitly, main becomes:

fn main(
  arg1: Vec<u64>,
  arg2: Vec<u64>,
) -> Vec<u64> {
  concat(arg1, arg2)
}

We shrunk the scope so we can say https://github.com/FuelLabs/sway/pull/3288 did it.

I think the least we have to do is:

• Improve attr parsing until building on it doesn't feel like a crime.
• Add cfg attr and macro, no cfg_attr, no target_arch, just cfg(evm)/cfg(fvm). (Names should be bikeshed.)

Some notes from my research are below. cc @mohammadfawaz

So it looks like we want to go for target_arch first: https://doc.rust-lang.org/reference/conditional-compilation.html#target_arch

It would look like this:

// The function is only included in the build when compiling for EVM
#[cfg(target_arch = "evm")]
fn evm_only() {
  // ...
}

This uses attributes which we have a very limited implementation of. This could be a good excuse to improve it and fix issues like https://github.com/FuelLabs/sway/issues/3576.

There is also a short form which we could implement along with the long form or just by itself:

#[cfg(evm)]
fn evm_only() {
  // ...
}

The short form shouldn't require any changes to the parser, so we could just go for this and not touch the parser at all, but I'm still for improving attr parsing a bit before we do this.

So the steps would be:

• Improve attribute support. This can be delivered early on a separate PR. This should serve all the parser/syntax needs.
• Add cfg attribute: https://doc.rust-lang.org/reference/conditional-compilation.html#the-cfg-attribute
• Add cfg_attr attribute: https://doc.rust-lang.org/reference/conditional-compilation.html#the-cfg_attr-attribute
• Add cfg macro: https://doc.rust-lang.org/reference/conditional-compilation.html#the-cfg-macro
• Add target_arch configuration option: https://doc.rust-lang.org/reference/conditional-compilation.html#target_arch

The toolchain file is used to pin a project to a certain version of the Rust toolchain.

We currently do not specify an actual version anywhere but just stable so I have followed that, but pinning it to an actual version like 1.65 could prevent new Clippy lints, etc. breaking our CI process when there's a new release.

Though, the file is useful even with just stable since it helps us clean the CI YAMLs.

Note: The current format of this file is actually TOML, but the GH action we're using doesn't support it yet so I had to use the legacy format. (The GH action also seems to be unmaintained: https://github.com/actions-rs/toolchain/issues/216)

I'm actually going to close this because I just couldn't find a convenient way of doing it. The action we currently use doesn't fully support our case and it's unmaintained so there's nothing we can do besides forking. There's an alternative but maintainer of that is refusing to implement support for the file. (This comment summarizes the situation well: https://github.com/actions-rs/toolchain/issues/126#issuecomment-1249931329)

I'll revisit if the situation changes.

This PR fixes the redirection introduced in #433.

Example route: https://fuellabs.github.io/fuel-specs/master/protocol/abi Old redirection: https://fuellabs.github.io/protocol/abi/index.html (No fuel-specs/master/, it's broken.) New redirection: https://fuellabs.github.io/fuel-specs/master/protocol/abi/index.html (All good.)

Split abi.md into multiple files (#433)

This PR splits the "ABI" section into three parts for easier access:

The actual content is left untouched.

This PR splits the "ABI" section into three parts for easier access:

The actual content is left untouched.

Pin to 1.65.0

Pin to a version

Leaving a redirect for every change like this sounds like it would introduce a lot of clutter in the long term, but this also makes users' bookmarks not break, etc.

Will you make sure that all links to the old abi.md file from the specs, the Sway Book, and the fuel book (if any) are updated?

How about a redirect? https://github.com/FuelLabs/fuel-specs/pull/433/commits/70a6936523b60142869cc1764c902fb37057da2a

Add redirect

Add rust-toolchain file

No default?

Override?

Old format?

No extension?

cc @ControlCplusControlV

The toolchain file is used to pin a project to a certain version of the Rust toolchain.

We currently do not specify a specific version, but just stable so I have followed that, but pinning it to an actual version like 1.65 could prevent new Clippy lints, etc. breaking our CI process when there's a new release.

Though, the file is useful even with just stable since it helps us clean the CI YAMLs.

This PR splits the "ABI" section into three parts for easier access:

The actual content is left untouched.

Bump to v0.31.1 (#3352)

Waiting on:

• [x] https://github.com/FuelLabs/sway/pull/3343

Merge branch 'master' into mohammadfawaz/enhance_option