Compute calldata offset on B256 argument

[digorithm]

Due to some changes somewhere (VM, compiler? Hard to say because as of now we don't have proper E2E tests and too many fast-moving pieces to pinpoint the actual root cause), contract calls with a single B256 argument stopped working because we're not including the calldata offset in the script_data.

This workaround (the check for calldata offset) will be removed entirely once this issue is done which is currently blocked by this one in the compiler.

However, this current problem (calls with B256 arg) is blocking @nfurfaro on his auth testing work. This PR unblocks him (see the test case I added to this PR, which is now passing).

This is an extremely simple solution: we're now computing calldata offset if the arg is a B256:

fn should_compute_call_data_offset(args: &[Token]) -> bool {
    match args
        .iter()
        .any(|t| matches!(t, Token::Struct(_) | Token::Enum(_) | Token::B256(_)))
    {
        true => true,
        false => args.len() > 1,
    }
}

That's the only significant change introduced by this PR. The rest of this PR is just adding the projects to test that specific case.

[mohammadfawaz]

The fuels-rs repo probably needs this: https://github.com/FuelLabs/sway/blob/master/.gitattributes for Sway syntax highlighting.

[mohammadfawaz]

Tuples should probably be on this list as well? Then there's probably the question about strings and arrays.

Maybe it's better if we invert the condition to check for copy types since they are a limited well defined set that will likely never change?

[digorithm]

We don't support tuples:

fuels-rs/packages/fuels-core/src/lib.rs

Lines 103 to 115 in 0c5b9f2

	pub enum Token {
	U8(u8),
	U16(u16),
	U32(u32),
	U64(u64),
	Bool(bool),
	Byte(u8),
	B256(Bits256),
	Array(Vec<Token>),
	String(String),
	Struct(Vec<Token>),
	Enum(Box<EnumSelector>),
	}

Maybe it's better if we invert the condition to check for copy types since they are a limited well defined set that will likely never change?

That's a good idea, but this whole thing will go away very soon, as soon as this is done. So I didn't wanna shake things too much, but I'm not married to this idea. What do you think?

[mohammadfawaz]

Ah of course, you're right... let's keep it as is :)

[iqdecay]

I agree with Rodrigo as well

[iqdecay]

Some nits, otherwise LGTM!

[iqdecay]

I agree with Rodrigo as well

[iqdecay]