553 commits

Author	SHA1	Message	Date
Daniel Frederico Lins Leite	6cc563d763	Trivial fns allowing control if a type is trivially encoded/decoded (#7501) ... ## Description Continuation of https://github.com/FuelLabs/sway/pull/7488. This PR introduces the option for each type to control its own `is_trivial`. Primitive data types have direct implementation (only decoding bool is false, as we need to guarantee its value is zero or one). Structs, tuples, arrays etc... are trivial if their runtime representation and "inner types" allow for trivial encoding or decoding. Enums are more complicated as we need to control that the enum tag is valid; they are not trivial. String arrays are not trivially encoded/decoded for backwards compatibility with "encoding v0" that needs padding in some cases. Some tests are showing a small regression (6 gas), which comes from the introduced "if" not being optimised away. I want to solve this in another PR, where the "if" condition will come from a const, and IR generation will guarantee that only one branch will ever be emitted. ## Snapshot "echo" Small QOL of snapshot was introduced with the "echo" command. It just prints the message directly, wrapping on 80 chars. The idea is to explain what the snapshot is trying to test. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > Add per-type trivial encode/decode flags and use raw_ptr fast paths in ABI (encode/decode) with supporting changes to codec, String/Vec, and tests. > > - **std/codec**: > - Introduce `AbiEncode::is_encode_trivial` and `AbiDecode::is_decode_trivial`; add helpers `is_encode_trivial/is_decode_trivial`. > - Switch `encode`/`abi_decode` to branch on triviality; add `decode_from_raw_ptr` and raw-ptr-based `decode_*` helpers. > - Make `BufferReader` parameter accessors return `raw_ptr`; minor refactors to use raw ptr copies. > - Implement triviality for primitives, arrays/tuples (conditional), `str[strN]` non-trivial, enums non-trivial. > - **std/string & std/vec**: implement trivial encode/decode markers (non-trivial) and adapt codec impls. > - **Tests/fixtures**: > - Update snapshots (IR/ASM/bytecode/gas), JSON ABI offsets, contract/predicate IDs, and logging expectations to match new encoding paths. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit dddd944aba. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY -->	2025-12-17 10:43:44 +11:00
Igor Rončević	c73137d717	Optionally remove test gas limit in forc test (#7495) ... ## Description This PR adds `--no-gas-limit` CLI option to `forc test`. The option increases tx gas limit in `forc test` to `u64::MAX`, essentially removing it. The motivation for the change was the need to benchmark heavy gas consuming algorithms. E.g., a brute force prime factorization of the number 9223372021822390277 took 21_474_836_627 gas units. The new `TestGasLimit` enum provides a `Limit(limit)` variant which is currently unused, but added for future extensions, if we want to limit the test gas to a particular value. ## Checklist - [ ] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-12-02 15:36:41 +13:00
Daniel Frederico Lins Leite	78aa952535	Trivially encoded types (#7488) ... ## Description This PR will slice https://github.com/FuelLabs/sway/pull/7419 into multiple PRS, being the first one. To start optimising encoding/decoding we will introduce the concept of "trivially encoded/decoded types". A type is trivially encoded or decoded if the encoding memory representation is the same as the runtime memory representation. PR #7419 introduced an intrinsic that would return a `bool` if both representations match. For this PR I decided to expose these memory representations directly. For that we have two new intrinsics: `__runtime_mem_id` and `__encoding_mem_id`. I am not 100% sure if they are going to be useful in other scenarios, but given that the optimiser is able to optimise them away, I think exposing them like this is better than what #7419 does. These `ids` are opaque numbers that do not convey anything about the type or their representation. They can only be compared for equality, and when a type does not have an encoding representation the intrinsic returns zero. With this in mind, the `encode` function now checks if a type is "trivially encoded" or not. If it is, we just allocate and memcopy its bytes. As this function should not return an aliased pointer. On top of that, we also have an `encode_and_return` function that avoids creating tuples and other stuff, given that the optimiser still generates some `mem_copy`s in these cases. A simple example of the benefit is the test `main_args_empty`, where the binary size went from 96 bytes to 64 bytes. Before ``` script { pub entry fn __entry() -> __ptr slice, !3 { local mut slice __aggr_memcpy_0 local { u64, u64 } __anon_0 local slice __ret_value entry(): v0 = get_local __ptr slice, __ret_value v1 = call main_0(), !6 v2 = get_local __ptr { u64, u64 }, __anon_0, !7 v3 = const u64 0 v4 = get_elem_ptr v2, __ptr u64, v3, !7 v5 = const u64 0, !8 store v5 to v4, !7 v6 = const u64 1 v7 = get_elem_ptr v2, __ptr u64, v6, !7 v8 = const u64 0, !9 store v8 to v7, !7 v9 = asm(s: v2) -> __ptr slice s { } v10 = get_local __ptr slice, __aggr_memcpy_0 mem_copy_val v10, v9 mem_copy_val v0, v10 ret __ptr slice v0 } entry_orig fn main_0() -> (), !13 { entry(): v0 = const unit () ret () v0 } } ;; ASM: Final program ;; Program kind: Script .program: move $$tmp $pc jmpf $zero i4 DATA_SECTION_OFFSET[0..32] DATA_SECTION_OFFSET[32..64] CONFIGURABLES_OFFSET[0..32] CONFIGURABLES_OFFSET[32..64] lw $$ds $$tmp i1 add $$ds $$ds $$tmp cfei i0 ; allocate stack space for globals move $$locbase $sp ; save locals base register for function __entry cfei i48 ; allocate 48 bytes for locals and 0 slots for call arguments addi $r0 $$locbase i32 ; get offset to local __ptr slice jal $$reta $pc i9 ; [call]: call main_0 addi $r1 $$locbase i16 ; get offset to local __ptr { u64, u64 } sw $$locbase $zero i2 ; store word sw $$locbase $zero i3 ; store word mcpi $$locbase $r1 i16 ; copy memory mcpi $r0 $$locbase i16 ; copy memory lw $r1 $r0 i1 ; load size of returned slice lw $r0 $r0 i0 ; load pointer to returned slice retd $r0 $r1 pshh i524288 ; save registers 40..64 move $$locbase $sp ; save locals base register for function main_0 poph i524288 ; restore registers 40..64 jal $zero $$reta i0 ; return from call .data: ``` After ``` script { pub entry fn __entry() -> __ptr never, !3 { entry(): v0 = call main_0(), !6 v1 = const u64 0, !7 v2 = const u64 0, !8 retd v1 v2, !9 } entry_orig fn main_0() -> (), !13 { entry(): v0 = const unit () ret () v0 } } ;; ASM: Final program ;; Program kind: Script .program: move $$tmp $pc jmpf $zero i4 DATA_SECTION_OFFSET[0..32] DATA_SECTION_OFFSET[32..64] CONFIGURABLES_OFFSET[0..32] CONFIGURABLES_OFFSET[32..64] lw $$ds $$tmp i1 add $$ds $$ds $$tmp cfei i0 ; allocate stack space for globals move $$locbase $sp ; save locals base register for function __entry jal $$reta $pc i2 ; [call]: call main_0 retd $zero $zero pshh i524288 ; save registers 40..64 move $$locbase $sp ; save locals base register for function main_0 poph i524288 ; restore registers 40..64 jal $zero $$reta i0 ; return from call .data: ``` Next PR will introduce this concept into the `AbiEncode` trait, allowing the type itself to control if it wants to be trivially encoded or not. # Missing optimizations If we look at the test `main_args_various_types`, after the `main` is called we see that IR is still not optimal. ``` v37 = get_local __ptr { u64 }, __ret_val1 v38 = call main_19(v36, v37) v39 = get_local __ptr { u64 }, _result, !58 <- not needed mem_copy_val v39, v37 <- not needed v40 = get_local __ptr { u64 }, _result, !59 <- not needed v41 = get_local __ptr { u64 }, item_, !62 <- not needed mem_copy_val v41, v40 <- not needed v42 = get_local __ptr { u64 }, item_, !64 <- not needed v43 = const u64 8 retd v42 v43, !66 ``` Ideally, IR would be ``` v37 = get_local __ptr { u64 }, __ret_val1 v38 = call main_19(v36, v37) v39 = const u64 8 retd v37 v39, !66 ``` ## Gas Usage Diff | Test | Before | After | Percentage | | ---- | -----: | ----: | ---------: | | should_fail/arith_overflow/u16_add_overflow (test.toml) | 44 | 43 | 2.27% | | should_fail/arith_overflow/u16_mul_overflow (test.toml) | 45 | 44 | 2.22% | | should_fail/arith_overflow/u16_sub_underflow (test.toml) | 23 | 22 | 4.35% | | should_fail/arith_overflow/u32_add_overflow (test.toml) | 44 | 43 | 2.27% | | should_fail/arith_overflow/u32_mul_overflow (test.toml) | 45 | 44 | 2.22% | | should_fail/arith_overflow/u32_sub_underflow (test.toml) | 23 | 22 | 4.35% | | should_fail/arith_overflow/u64_add_overflow (test.toml) | 17 | 15 | 11.76% | | should_fail/arith_overflow/u64_mul_overflow (test.toml) | 18 | 16 | 11.11% | | should_fail/arith_overflow/u64_sub_underflow (test.toml) | 16 | 14 | 12.50% | | should_fail/arith_overflow/u8_add_overflow (test.toml) | 38 | 36 | 5.26% | | should_fail/arith_overflow/u8_mul_overflow (test.toml) | 39 | 37 | 5.13% | | should_fail/arith_overflow/u8_sub_underflow (test.toml) | 17 | 15 | 11.76% | | should_fail/vec_set_index_out_of_bounds (test.toml) | 182 | 179 | 1.65% | | should_fail/vec_swap_param1_out_of_bounds (test.toml) | 237 | 234 | 1.27% | | should_fail/vec_swap_param2_out_of_bounds (test.toml) | 241 | 238 | 1.24% | | should_pass/blanket_impl (test.toml) | 142 | 51 | 64.08% | | should_pass/blanket_impl_u16 (test.toml) | 142 | 51 | 64.08% | | should_pass/break_in_non_statement_positions (test.toml) | 142 | 51 | 64.08% | | should_pass/conditional_compilation/run (test.toml) | 142 | 51 | 64.08% | | should_pass/continue_in_non_statement_positions (test.toml) | 1226 | 1135 | 7.42% | | should_pass/empty_fields_in_storage_struct (test.toml)::test_read_write_bytes | 11204 | 10275 | 8.29% | | should_pass/empty_fields_in_storage_struct (test.toml)::test_read_write_map | 7865 | 7107 | 9.64% | | should_pass/empty_fields_in_storage_struct (test.toml)::test_read_write_vec | 11474 | 10125 | 11.76% | | should_pass/forc/dependency_package_field (test.toml) | 137 | 46 | 66.42% | | should_pass/language/abort_control_flow_good (test.toml) | 29 | 27 | 6.90% | | should_pass/language/addrof_intrinsic (test.toml) | 609 | 595 | 2.30% | | should_pass/language/aliased_imports (test.toml) | 144 | 53 | 63.19% | | should_pass/language/args_on_stack (test.toml) | 5037 | 4946 | 1.81% | | should_pass/language/array/array_basics (test.toml) | 478 | 387 | 19.04% | | should_pass/language/array/array_generics (test.toml) | 146 | 55 | 62.33% | | should_pass/language/asm_expr_basic (test.toml) | 163 | 135 | 17.18% | | should_pass/language/associated_const_abi (test.toml)::test | 4546 | 4096 | 9.90% | | should_pass/language/associated_const_abi_multiple (test.toml)::test | 1510 | 1360 | 9.93% | | should_pass/language/associated_const_impl (test.toml) | 143 | 115 | 19.58% | | should_pass/language/associated_const_impl_local_same_name (test.toml) | 143 | 115 | 19.58% | | should_pass/language/associated_const_impl_self (test.toml) | 166 | 138 | 16.87% | | should_pass/language/associated_const_in_decls_of_other_constants (test.toml)::test | 529 | 452 | 14.56% | | should_pass/language/associated_const_trait_impl_method (test.toml) | 143 | 115 | 19.58% | | should_pass/language/associated_const_trait_method (test.toml) | 143 | 115 | 19.58% | | should_pass/language/associated_type_and_associated_const (test.toml) | 143 | 115 | 19.58% | | should_pass/language/associated_type_ascription (test.toml) | 143 | 115 | 19.58% | | should_pass/language/associated_type_container (test.toml) | 602 | 560 | 6.98% | | should_pass/language/associated_type_container_in_library (test.toml) | 602 | 560 | 6.98% | | should_pass/language/associated_type_fully_qualified (test.toml) | 195 | 152 | 22.05% | | should_pass/language/associated_type_iterator (test.toml) | 620 | 578 | 6.77% | | should_pass/language/associated_type_method (test.toml) | 143 | 115 | 19.58% | | should_pass/language/associated_type_parameter (test.toml) | 143 | 115 | 19.58% | | should_pass/language/b256_bad_jumps (test.toml) | 137 | 46 | 66.42% | | should_pass/language/b256_bitwise_ops (test.toml) | 1503 | 1412 | 6.05% | | should_pass/language/b256_ops (test.toml) | 1314 | 1223 | 6.93% | | should_pass/language/basic_func_decl (test.toml) | 136 | 45 | 66.91% | | should_pass/language/binary_and_hex_literals (test.toml) | 136 | 45 | 66.91% | | should_pass/language/binop_intrinsics (test.toml) | 142 | 51 | 64.08% | | should_pass/language/bitwise_not (test.toml) | 136 | 45 | 66.91% | | should_pass/language/blanket_trait (test.toml) | 136 | 45 | 66.91% | | should_pass/language/bool_and_or (test.toml) | 142 | 51 | 64.08% | | should_pass/language/break_and_continue (test.toml) | 1098 | 1007 | 8.29% | | should_pass/language/builtin_type_method_call (test.toml) | 142 | 51 | 64.08% | | should_pass/language/chained_if_let (test.toml) | 166 | 75 | 54.82% | | should_pass/language/complex_ir_cfg (test.toml) | 158 | 142 | 10.13% | | should_pass/language/configurable_consts (test.toml) | 2520 | 2506 | 0.56% | | should_pass/language/configurable_tests (test.toml)::t | 2805 | 2553 | 8.98% | | should_pass/language/const_decl_and_use_in_library (test.toml) | 142 | 51 | 64.08% | | should_pass/language/const_decl_in_library (test.toml) | 148 | 57 | 61.49% | | should_pass/language/const_generics (test.toml) | 318 | 305 | 4.09% | | should_pass/language/const_inits (test.toml) | 481 | 390 | 18.92% | | should_pass/language/contract_caller_dynamic_address (test.toml) | 379 | 301 | 20.58% | | should_pass/language/contract_ret_intrinsic (test.toml)::test | 1464 | 1314 | 10.25% | | should_pass/language/dereferenced_projection_reassignment (test.toml) | 238 | 124 | 47.90% | | should_pass/language/diverging_exprs (test.toml) | 291 | 200 | 31.27% | | should_pass/language/dummy_method_issue (test.toml) | 134 | 120 | 10.45% | | should_pass/language/empty_method_initializer (test.toml) | 242 | 151 | 37.60% | | should_pass/language/enum_destructuring (test.toml) | 156 | 65 | 58.33% | | should_pass/language/enum_if_let (test.toml) | 221 | 130 | 41.18% | | should_pass/language/enum_if_let_large_type (test.toml) | 201 | 110 | 45.27% | | should_pass/language/enum_in_fn_decl (test.toml) | 157 | 66 | 57.96% | | should_pass/language/enum_init_fn_call (test.toml) | 185 | 94 | 49.19% | | should_pass/language/enum_instantiation (test.toml) | 660 | 569 | 13.79% | | should_pass/language/enum_padding (test.toml) | 518 | 487 | 5.98% | | should_pass/language/enum_type_inference (test.toml) | 142 | 51 | 64.08% | | should_pass/language/enum_variant_imports (test.toml) | 161 | 70 | 56.52% | | should_pass/language/eq_and_neq (test.toml) | 675 | 584 | 13.48% | | should_pass/language/eq_intrinsic (test.toml) | 142 | 51 | 64.08% | | should_pass/language/far_jumps/many_blobs (test.toml) | 3670216 | 3670125 | 0.00% | | should_pass/language/far_jumps/single_blob (test.toml) | 142 | 51 | 64.08% | | should_pass/language/for_loops (test.toml) | 7882 | 7791 | 1.15% | | should_pass/language/funcs_with_generic_types (test.toml) | 136 | 45 | 66.91% | | should_pass/language/function_return_type_unification (test.toml) | 148 | 120 | 18.92% | | should_pass/language/generic_functions (test.toml) | 136 | 45 | 66.91% | | should_pass/language/generic_impl_self (test.toml) | 740 | 712 | 3.78% | | should_pass/language/generic_impl_self_where (test.toml) | 790 | 699 | 11.52% | | should_pass/language/generic_inside_generic (test.toml) | 163 | 72 | 55.83% | | should_pass/language/generic_result_method (test.toml) | 330 | 239 | 27.58% | | should_pass/language/generic_struct (test.toml) | 136 | 45 | 66.91% | | should_pass/language/generic_struct_instantiation (test.toml) | 137 | 46 | 66.42% | | should_pass/language/generic_structs (test.toml) | 136 | 45 | 66.91% | | should_pass/language/generic_trait_constraints (test.toml) | 187 | 62 | 66.84% | | should_pass/language/generic_traits (test.toml) | 415 | 324 | 21.93% | | should_pass/language/generic_transpose (test.toml) | 215 | 124 | 42.33% | | should_pass/language/generic_tuple_trait (test.toml) | 174 | 83 | 52.30% | | should_pass/language/generic_type_inference (test.toml) | 1349 | 1335 | 1.04% | | should_pass/language/generic_where_in_impl_self (test.toml) | 201 | 110 | 45.27% | | should_pass/language/generic_where_in_impl_self2 (test.toml) | 201 | 110 | 45.27% | | should_pass/language/gtf_intrinsic (test.toml) | 286 | 195 | 31.82% | | should_pass/language/if_elseif_enum (test.toml) | 388 | 360 | 7.22% | | should_pass/language/if_implicit_unit (test.toml) | 55 | 41 | 25.45% | | should_pass/language/if_let_no_side_effects (test.toml) | 154 | 63 | 59.09% | | should_pass/language/impl_self_method (test.toml) | 148 | 120 | 18.92% | | should_pass/language/impl_self_method_order (test.toml) | 148 | 120 | 18.92% | | should_pass/language/implicit_casting (test.toml) | 142 | 51 | 64.08% | | should_pass/language/implicit_return (test.toml) | 142 | 51 | 64.08% | | should_pass/language/import_method_from_other_file (test.toml) | 155 | 64 | 58.71% | | should_pass/language/import_star_name_clash (test.toml) | 1039 | 948 | 8.76% | | should_pass/language/import_trailing_comma (test.toml) | 143 | 52 | 63.64% | | should_pass/language/import_with_different_callpaths (test.toml) | 793 | 779 | 1.77% | | should_pass/language/impure_ifs (test.toml) | 429 | 338 | 21.21% | | should_pass/language/inline_if_expr_const (test.toml) | 55 | 41 | 25.45% | | should_pass/language/insert_element_reg_reuse (test.toml) | 1794 | 1703 | 5.07% | | should_pass/language/integer_type_inference (test.toml) | 547 | 533 | 2.56% | | should_pass/language/intrinsics/dbg (test.toml) | 1193 | 1102 | 7.63% | | should_pass/language/intrinsics/dbg_release (test.toml) | 9785 | 9694 | 0.93% | | should_pass/language/intrinsics/transmute (test.toml) | 402 | 388 | 3.48% | | should_pass/language/is_prime (test.toml) | 1047 | 956 | 8.69% | | should_pass/language/is_reference_type (test.toml) | 136 | 45 | 66.91% | | should_pass/language/left_to_right_func_args_evaluation (test.toml) | 149 | 58 | 61.07% | | should_pass/language/local_impl_for_ord (test.toml) | 136 | 45 | 66.91% | | should_pass/language/logging (test.toml) | 2126 | 1790 | 15.80% | | should_pass/language/main_args/main_args_empty (test.encoding_v1.toml) | 142 | 41 | 71.13% | | should_pass/language/main_args/main_args_empty (test.toml) | 19 | 18 | 5.26% | | should_pass/language/main_args/main_args_generics (test.toml) | 504 | 472 | 6.35% | | should_pass/language/main_args/main_args_one_u64 (test.toml) | 163 | 63 | 61.35% | | should_pass/language/main_args/main_args_ref (test.toml) | 172 | 72 | 58.14% | | should_pass/language/main_args/main_args_ref_copy (test.toml) | 181 | 81 | 55.25% | | should_pass/language/main_args/main_args_ref_ref (test.toml) | 226 | 125 | 44.69% | | should_pass/language/main_args/main_args_two_u64 (test.toml) | 172 | 72 | 58.14% | | should_pass/language/main_args/main_args_various_types (test.toml) | 1283 | 1130 | 11.93% | | should_pass/language/main_returns_unit (test.toml) | 55 | 41 | 25.45% | | should_pass/language/many_stack_variables (test.toml) | 151 | 60 | 60.26% | | should_pass/language/match_expressions_all (test.toml) | 3699 | 3685 | 0.38% | | should_pass/language/match_expressions_constants (test.toml) | 377 | 263 | 30.24% | | should_pass/language/match_expressions_empty_enums (test.toml) | 142 | 51 | 64.08% | | should_pass/language/match_expressions_enums (test.toml) | 2019 | 1928 | 4.51% | | should_pass/language/match_expressions_explicit_rets (test.toml) | 136 | 45 | 66.91% | | should_pass/language/match_expressions_inside_generic_functions (test.toml) | 170 | 79 | 53.53% | | should_pass/language/match_expressions_mismatched (test.toml) | 154 | 63 | 59.09% | | should_pass/language/match_expressions_nested (test.toml) | 649 | 621 | 4.31% | | should_pass/language/match_expressions_rest (test.toml) | 777 | 686 | 11.71% | | should_pass/language/match_expressions_simple (test.toml) | 156 | 65 | 58.33% | | should_pass/language/match_expressions_structs (test.toml) | 151 | 60 | 60.26% | | should_pass/language/match_expressions_with_self (test.toml) | 163 | 72 | 55.83% | | should_pass/language/memcpy (test.toml) | 266 | 175 | 34.21% | | should_pass/language/method_indirect_inference (test.toml) | 218 | 127 | 41.74% | | should_pass/language/method_nested_type_args (test.toml) | 55 | 41 | 25.45% | | should_pass/language/method_on_empty_struct (test.toml) | 137 | 46 | 66.42% | | should_pass/language/method_on_primitives (test.toml) | 99 | 85 | 14.14% | | should_pass/language/method_unambiguous (test.toml) | 186 | 95 | 48.92% | | should_pass/language/modulo_uint_test (test.toml) | 136 | 45 | 66.91% | | should_pass/language/multi_impl_self (test.toml) | 142 | 51 | 64.08% | | should_pass/language/multi_item_import (test.toml) | 136 | 45 | 66.91% | | should_pass/language/mutable_and_initd (test.toml) | 157 | 66 | 57.96% | | should_pass/language/mutable_arrays (test.toml) | 142 | 51 | 64.08% | | should_pass/language/mutable_arrays_enum (test.toml) | 153 | 62 | 59.48% | | should_pass/language/mutable_arrays_multiple_nested (test.toml) | 137 | 46 | 66.42% | | should_pass/language/mutable_arrays_nested (test.toml) | 137 | 46 | 66.42% | | should_pass/language/mutable_arrays_struct (test.toml) | 142 | 51 | 64.08% | | should_pass/language/mutable_arrays_swap (test.toml) | 142 | 51 | 64.08% | | should_pass/language/name_resolution_after_monomorphization (test.toml) | 148 | 57 | 61.49% | | should_pass/language/nested_generics (test.toml) | 136 | 45 | 66.91% | | should_pass/language/nested_struct_destructuring (test.toml) | 137 | 46 | 66.42% | | should_pass/language/nested_structs (test.toml) | 279 | 188 | 32.62% | | should_pass/language/nested_while_and_if (test.toml) | 194 | 103 | 46.91% | | should_pass/language/new_allocator_test (test.toml) | 204 | 113 | 44.61% | | should_pass/language/non_literal_const_decl (test.toml) | 142 | 51 | 64.08% | | should_pass/language/numeric_constants (test.toml) | 170 | 45 | 73.53% | | should_pass/language/numeric_type_propagation (test.toml) | 170 | 45 | 73.53% | | should_pass/language/op_precedence (test.toml) | 136 | 45 | 66.91% | | should_pass/language/ops (test.toml) | 155 | 64 | 58.71% | | should_pass/language/out_of_order_decl (test.toml) | 136 | 45 | 66.91% | | should_pass/language/overlapped_trait_impls (test.toml) | 276 | 185 | 32.97% | | should_pass/language/prelude_access (test.toml) | 55 | 41 | 25.45% | | should_pass/language/prelude_access2 (test.toml) | 55 | 41 | 25.45% | | should_pass/language/primitive_type_argument (test.toml) | 142 | 51 | 64.08% | | should_pass/language/pusha_popa_multiple_defreg (test.toml)::incorrect_pusha_popa | 451 | 409 | 9.31% | | should_pass/language/raw_identifiers (test.error_type.toml)::test | 903 | 738 | 18.27% | | should_pass/language/raw_identifiers (test.toml)::test | 903 | 738 | 18.27% | | should_pass/language/raw_ptr/vec_ret (test.toml) | 637 | 605 | 5.02% | | should_pass/language/reassignment_operators (test.toml) | 137 | 46 | 66.42% | | should_pass/language/reassignment_rhs_lhs_evaluation_order (test.toml) | 202 | 89 | 55.94% | | should_pass/language/redundant_return (test.toml) | 137 | 46 | 66.42% | | should_pass/language/reexport/aliases (test.toml) | 301 | 210 | 30.23% | | should_pass/language/reexport/multiple_imports_of_same_reexport (test.toml) | 329 | 238 | 27.66% | | should_pass/language/reexport/reexport_paths (test.toml) | 277 | 165 | 40.43% | | should_pass/language/reexport/shadowing_in_reexporting_module (test.toml) | 368 | 277 | 24.73% | | should_pass/language/reexport/simple_glob_import (test.toml) | 216 | 125 | 42.13% | | should_pass/language/reexport/simple_item_import (test.toml) | 216 | 125 | 42.13% | | should_pass/language/reexport/visibility (test.toml) | 216 | 125 | 42.13% | | should_pass/language/ref_mutable_arrays (test.toml) | 142 | 51 | 64.08% | | should_pass/language/ref_mutable_arrays_inline (test.toml) | 142 | 51 | 64.08% | | should_pass/language/ref_mutable_fn_args_bool (test.toml) | 136 | 45 | 66.91% | | should_pass/language/ref_mutable_fn_args_call (test.toml) | 142 | 51 | 64.08% | | should_pass/language/ref_mutable_fn_args_struct (test.toml) | 142 | 51 | 64.08% | | should_pass/language/ref_mutable_fn_args_struct_assign (test.toml) | 142 | 51 | 64.08% | | should_pass/language/ref_mutable_fn_args_u32 (test.toml) | 148 | 120 | 18.92% | | should_pass/language/references/dereferencing_control_flow_expressions (test.toml) | 652 | 540 | 17.18% | | should_pass/language/references/impl_reference_types (test.toml) | 2084 | 1902 | 8.73% | | should_pass/language/references/mutability_of_references (test.toml) | 233 | 142 | 39.06% | | should_pass/language/references/mutability_of_references_memcpy_bug (test.toml)::test | 1023 | 680 | 33.53% | | should_pass/language/references/reassigning_via_references_in_aggregates (test.toml) | 2435 | 2297 | 5.67% | | should_pass/language/references/references_and_type_aliases (test.toml) | 222 | 131 | 40.99% | | should_pass/language/references/references_in_aggregates (test.toml) | 3010 | 2919 | 3.02% | | should_pass/language/references/references_in_asm_blocks (test.toml) | 800 | 709 | 11.38% | | should_pass/language/references/referencing_control_flow_expressions (test.toml) | 841 | 750 | 10.82% | | should_pass/language/references/referencing_function_parameters (test.toml) | 2292 | 2201 | 3.97% | | should_pass/language/references/referencing_function_parameters_simple (test.toml)::test_arg_addr | 1268 | 464 | 63.41% | | should_pass/language/references/referencing_parts_of_aggregates (test.toml) | 2124 | 2033 | 4.28% | | should_pass/language/references/referencing_references (test.toml) | 417 | 326 | 21.82% | | should_pass/language/references/type_unification_of_references (test.toml) | 539 | 448 | 16.88% | | should_pass/language/ret_small_string (test.toml) | 169 | 138 | 18.34% | | should_pass/language/ret_string_in_struct (test.toml) | 185 | 153 | 17.30% | | should_pass/language/retd_b256 (test.toml) | 188 | 74 | 60.64% | | should_pass/language/retd_small_array (test.toml) | 196 | 164 | 16.33% | | should_pass/language/retd_struct (test.toml) | 362 | 331 | 8.56% | | should_pass/language/retd_zero_len_array (test.toml) | 107 | 75 | 29.91% | | should_pass/language/revert_in_first_if_branch (test.toml) | 28 | 25 | 10.71% | | should_pass/language/same_const_name (test.toml) | 55 | 41 | 25.45% | | should_pass/language/self_impl_reassignment (test.toml) | 276 | 185 | 32.97% | | should_pass/language/shadowing/shadowed_glob_imports (test.toml) | 178 | 87 | 51.12% | | should_pass/language/shadowing/shadowed_prelude_imports (test.toml) | 146 | 55 | 62.33% | | should_pass/language/size_of (test.toml) | 137 | 46 | 66.42% | | should_pass/language/slice/slice_intrinsics (test.toml) | 123848 | 104394 | 15.71% | | should_pass/language/slice/slice_script (test.toml) | 231 | 200 | 13.42% | | should_pass/language/storage_slot_sized (test.toml)::test_store_something | 7736 | 4706 | 39.17% | | should_pass/language/string_slice/string_slice_features (test.toml) | 163 | 72 | 55.83% | | should_pass/language/string_slice/string_slice_script (test.toml) | 264 | 232 | 12.12% | | should_pass/language/struct_destructuring (test.toml) | 142 | 51 | 64.08% | | should_pass/language/struct_field_access (test.toml) | 142 | 51 | 64.08% | | should_pass/language/struct_field_reassignment (test.toml) | 137 | 46 | 66.42% | | should_pass/language/struct_instantiation (test.toml) | 524 | 433 | 17.37% | | should_pass/language/supertraits (test.toml) | 1146 | 1055 | 7.94% | | should_pass/language/supertraits_with_trait_methods (test.toml) | 151 | 60 | 60.26% | | should_pass/language/totalord (test.toml) | 783 | 658 | 15.96% | | should_pass/language/trait_constraint_param_order (test.toml) | 136 | 45 | 66.91% | | should_pass/language/trait_generic_override (test.toml) | 136 | 45 | 66.91% | | should_pass/language/trait_import_with_star (test.toml) | 55 | 41 | 25.45% | | should_pass/language/trait_inference (test.toml) | 182 | 57 | 68.68% | | should_pass/language/trait_method_ascription_disambiguate (test.toml) | 136 | 45 | 66.91% | | should_pass/language/trait_method_generic_qualified (test.toml) | 136 | 45 | 66.91% | | should_pass/language/trait_method_qualified (test.toml) | 136 | 45 | 66.91% | | should_pass/language/trait_nested (test.toml) | 189 | 64 | 66.14% | | should_pass/language/tuple_access (test.toml) | 176 | 85 | 51.70% | | should_pass/language/tuple_desugaring (test.toml) | 155 | 127 | 18.06% | | should_pass/language/tuple_field_reassignment (test.toml) | 168 | 77 | 54.17% | | should_pass/language/tuple_in_struct (test.toml) | 199 | 108 | 45.73% | | should_pass/language/tuple_indexing (test.toml) | 143 | 115 | 19.58% | | should_pass/language/tuple_single_element (test.toml) | 149 | 58 | 61.07% | | should_pass/language/tuple_trait (test.toml) | 152 | 61 | 59.87% | | should_pass/language/tuple_types (test.toml) | 148 | 120 | 18.92% | | should_pass/language/type_alias (test.toml) | 1064 | 1050 | 1.32% | | should_pass/language/type_inference_propagation_of_type_constraints (test.toml) | 268 | 237 | 11.57% | | should_pass/language/typeinfo_custom_callpath (test.toml) | 67 | 53 | 20.90% | | should_pass/language/typeinfo_custom_callpath2 (test.toml) | 67 | 53 | 20.90% | | should_pass/language/typeinfo_custom_callpath_with_import (test.toml) | 69 | 55 | 20.29% | | should_pass/language/u256/u256_abi (test.toml) | 392 | 164 | 58.16% | | should_pass/language/unary_not_basic (test.toml) | 136 | 45 | 66.91% | | should_pass/language/unary_not_basic_2 (test.toml) | 136 | 45 | 66.91% | | should_pass/language/unify_never (test.toml) | 142 | 51 | 64.08% | | should_pass/language/unit_type_variants (test.toml) | 224 | 53 | 76.34% | | should_pass/language/use_absolute_path (test.toml) | 137 | 46 | 66.42% | | should_pass/language/use_full_path_names (test.toml) | 143 | 115 | 19.58% | | should_pass/language/where_clause_enums (test.toml) | 280 | 189 | 32.50% | | should_pass/language/where_clause_functions (test.toml) | 453 | 362 | 20.09% | | should_pass/language/where_clause_generic_traits (test.toml) | 55 | 41 | 25.45% | | should_pass/language/where_clause_generic_tuple (test.toml) | 142 | 51 | 64.08% | | should_pass/language/where_clause_impls (test.toml) | 158 | 67 | 57.59% | | should_pass/language/where_clause_methods (test.toml) | 541 | 450 | 16.82% | | should_pass/language/where_clause_structs (test.toml) | 254 | 163 | 35.83% | | should_pass/language/where_clause_traits (test.toml) | 136 | 45 | 66.91% | | should_pass/language/while_loops (test.toml) | 389 | 298 | 23.39% | | should_pass/language/zero_field_types (test.toml) | 142 | 51 | 64.08% | | should_pass/return_in_non_statement_positions (test.toml) | 142 | 51 | 64.08% | | should_pass/return_into (test.toml) | 412 | 321 | 22.09% | | should_pass/stdlib/address_test (test.toml) | 1175 | 1084 | 7.74% | | should_pass/stdlib/alloc_test (test.toml) | 265 | 174 | 34.34% | | should_pass/stdlib/assert_eq (test.toml) | 1108 | 983 | 11.28% | | should_pass/stdlib/assert_eq_revert (test.toml) | 303 | 152 | 49.83% | | should_pass/stdlib/assert_ne (test.toml) | 1045 | 921 | 11.87% | | should_pass/stdlib/assert_ne_revert (test.toml) | 302 | 151 | 50.00% | | should_pass/stdlib/assert_test (test.toml) | 136 | 45 | 66.91% | | should_pass/stdlib/asset_id_into_bytes (test.toml) | 173 | 82 | 52.60% | | should_pass/stdlib/b512_struct_alignment (test.toml) | 202 | 111 | 45.05% | | should_pass/stdlib/b512_test (test.toml) | 996 | 905 | 9.14% | | should_pass/stdlib/block_height (test.toml) | 149 | 58 | 61.07% | | should_pass/stdlib/chess (test.toml) | 231 | 140 | 39.39% | | should_pass/stdlib/contract_id_test (test.toml) | 174 | 83 | 52.30% | | should_pass/stdlib/contract_id_type (test.toml) | 169 | 78 | 53.85% | | should_pass/stdlib/eq_generic (test.toml) | 154 | 140 | 9.09% | | should_pass/stdlib/ge_test (test.toml) | 136 | 45 | 66.91% | | should_pass/stdlib/generic_empty_struct_with_constraint (test.toml) | 55 | 41 | 25.45% | | should_pass/stdlib/identity_eq (test.toml) | 1274 | 1183 | 7.14% | | should_pass/stdlib/if_type_revert (test.toml) | 26 | 24 | 7.69% | | should_pass/stdlib/intrinsics (test.toml) | 136 | 45 | 66.91% | | should_pass/stdlib/iterator (test.toml) | 984 | 859 | 12.70% | | should_pass/stdlib/option_eq (test.toml) | 5291 | 5200 | 1.72% | | should_pass/stdlib/raw_ptr (test.toml) | 4316 | 4225 | 2.11% | | should_pass/stdlib/raw_slice (test.toml) | 424 | 392 | 7.55% | | should_pass/stdlib/require (test.toml) | 182 | 165 | 9.34% | | should_pass/stdlib/storage_vec_insert (test.toml)::test_test_function | 2903 | 2754 | 5.13% | | should_pass/stdlib/u128_div_test (test.toml) | 34133 | 34042 | 0.27% | | should_pass/stdlib/u128_log_test (test.toml) | 11809 | 11718 | 0.77% | | should_pass/stdlib/u128_mul_test (test.toml) | 453 | 362 | 20.09% | | should_pass/stdlib/u128_root_test (test.toml) | 7634 | 7543 | 1.19% | | should_pass/stdlib/u128_test (test.toml) | 2177 | 2086 | 4.18% | | should_pass/stdlib/vec (test.toml) | 65253 | 65162 | 0.14% | | should_pass/stdlib/vec_swap (test.toml) | 14862 | 14771 | 0.61% | | should_pass/storage_element_key_modification (test.toml)::test_storage_key_address | 943 | 863 | 8.48% | | should_pass/storage_element_key_modification (test.toml)::test_storage_key_modification | 465 | 385 | 17.20% | | should_pass/storage_slot_key_calculation (test.toml)::test | 2785 | 2708 | 2.76% | | should_pass/superabi_contract_calls (test.toml)::tests | 1310 | 1004 | 23.36% | | should_pass/superabi_supertrait_same_methods (test.toml)::tests | 634 | 483 | 23.82% | | should_pass/test_abis/abi_impl_methods_callable (test.toml)::tests | 599 | 449 | 25.04% | | should_pass/test_abis/contract_abi-auto_impl (test.toml)::tests | 599 | 449 | 25.04% | | should_pass/test_contracts/basic_storage (test.toml)::collect_basic_storage_contract_gas_usages | 37164 | 35842 | 3.56% | | should_pass/test_contracts/increment_contract (test.toml)::collect_incrementor_contract_gas_usages | 2006 | 1628 | 18.84% | | should_pass/test_contracts/return_struct (test.toml)::collect_my_contract_gas_usages | 1076 | 1000 | 7.06% | | should_pass/test_contracts/storage_access_contract (test.toml)::collect_storage_access_contract_gas_usages | 49894 | 44857 | 10.10% | | should_pass/test_contracts/storage_enum_contract (test.toml)::collect_storage_enum_contract_gas_usages | 22372 | 22213 | 0.71% | | should_pass/unit_tests/aggr_indexing (test.toml)::test1 | 4192 | 2082 | 50.33% | | should_pass/unit_tests/contract-multi-contract-calls (test.toml)::test_contract_2_call | 631 | 480 | 23.93% | | should_pass/unit_tests/contract-multi-contract-calls (test.toml)::test_contract_call | 634 | 483 | 23.82% | | should_pass/unit_tests/contract-multi-contract-calls (test.toml)::test_contract_multi_call | 1246 | 944 | 24.24% | | should_pass/unit_tests/contract_multi_test (test.toml)::test_bar | 175 | 68 | 61.14% | | should_pass/unit_tests/contract_multi_test (test.toml)::test_fail | 635 | 484 | 23.78% | | should_pass/unit_tests/contract_multi_test (test.toml)::test_success | 633 | 482 | 23.85% | | should_pass/unit_tests/contract_with_nested_libs (test.toml)::log_test | 180 | 184 | -2.22% | | should_pass/unit_tests/contract_with_nested_libs (test.toml)::log_test_inner | 180 | 184 | -2.22% | | should_pass/unit_tests/contract_with_nested_libs (test.toml)::log_test_inner2 | 173 | 67 | 61.27% | | should_pass/unit_tests/lib_log_decode (test.toml)::math_u16_overflow_mul | 214 | 218 | -1.87% | | should_pass/unit_tests/lib_log_decode (test.toml)::math_u32_overflow_mul | 214 | 218 | -1.87% | | should_pass/unit_tests/lib_log_decode (test.toml)::test_fn | 362 | 146 | 59.67% | | should_pass/unit_tests/lib_multi_test (test.toml)::test_gt | 156 | 82 | 47.44% | | should_pass/unit_tests/lib_multi_test (test.toml)::test_local | 156 | 82 | 47.44% | | should_pass/unit_tests/nested_libs (test.toml)::log_test | 179 | 183 | -2.23% | | should_pass/unit_tests/nested_libs (test.toml)::log_test_inner | 179 | 183 | -2.23% | | should_pass/unit_tests/nested_libs (test.toml)::log_test_inner2 | 172 | 66 | 61.63% | | should_pass/unit_tests/regalloc_spill (test.toml) | 181 | 90 | 50.28% | | should_pass/unit_tests/script-contract-calls (test.toml)::test_contract_call | 563 | 448 | 20.43% | | should_pass/unit_tests/script_log_decode (test.toml)::test_fn | 294 | 146 | 50.34% | | should_pass/unit_tests/script_with_nested_libs (test.toml)::log_test | 179 | 183 | -2.23% | | should_pass/unit_tests/script_with_nested_libs (test.toml)::log_test_inner | 179 | 183 | -2.23% | | should_pass/unit_tests/script_with_nested_libs (test.toml)::log_test_inner2 | 172 | 66 | 61.63% | | should_pass/unit_tests/workspace_test (test.toml)::test_bar | 175 | 68 | 61.14% | | should_pass/unit_tests/workspace_test (test.toml)::test_fail | 635 | 484 | 23.78% | | should_pass/unit_tests/workspace_test (test.toml)::test_gt | 156 | 82 | 47.44% | | should_pass/unit_tests/workspace_test (test.toml)::test_local | 156 | 82 | 47.44% | | should_pass/unit_tests/workspace_test (test.toml)::test_success | 634 | 483 | 23.82% | | | Improvements | Regressions | | - | -: | -: | | Count | 346 | 8 | | Average | 34.98% | -2.14% | | Median | 28.79% | -2.23% | | Max | 76.34% | -2.23% | | Min | 0.14% | -1.87% | | Test | Before | After | Percentage | | ---- | -----: | ----: | ---------: | | assert_inline_tests::assert_assert_eq | 1576 | 1529 | 2.98% | | assert_inline_tests::assert_assert_ne | 1630 | 1585 | 2.76% | | assert_inline_tests::revert_assert_assert_eq | 1480 | 1117 | 24.53% | | assert_inline_tests::revert_assert_assert_ne | 1488 | 1115 | 25.07% | | asset_id_contract_tests::asset_id_default | 10994 | 10696 | 2.71% | | bytes_inline_tests::bytes_append | 5789 | 5787 | 0.03% | | bytes_inline_tests::bytes_split_at_twice | 1321 | 1319 | 0.15% | | codec_implemented_tests::test_logging | 51837 | 23126 | 55.39% | | contract_id_contract_tests::contract_id_this | 10787 | 10488 | 2.77% | | crypto_ed25519_inline_tests::ed25519_codec | 6125 | 640 | 89.55% | | crypto_secp256k1_inline_tests::secp256k1_codec | 6125 | 640 | 89.55% | | crypto_secp256r1_inline_tests::secp256r1_codec | 6125 | 640 | 89.55% | | crypto_signature_inline_tests::signature_as_ed25519 | 6840 | 6841 | -0.01% | | crypto_signature_inline_tests::signature_as_secp256r1 | 6836 | 6837 | -0.01% | | crypto_signature_inline_tests::signature_codec | 7748 | 654 | 91.56% | | crypto_signature_inline_tests::signature_verify | 43208 | 43205 | 0.01% | | hash_inline_tests::hash_address | 7223 | 7211 | 0.17% | | hash_inline_tests::hash_asset_id | 7223 | 7211 | 0.17% | | hash_inline_tests::hash_b256 | 7171 | 7159 | 0.17% | | hash_inline_tests::hash_call_params | 6930 | 6924 | 0.09% | | hash_inline_tests::hash_contract_id | 7223 | 7211 | 0.17% | | hash_inline_tests::hash_evm_address | 7407 | 7395 | 0.16% | | hash_inline_tests::hash_identity | 17767 | 17743 | 0.14% | | hash_inline_tests::hash_point2d | 9311 | 9305 | 0.06% | | hash_inline_tests::hash_signature | 20238 | 20220 | 0.09% | | hash_inline_tests::hash_str | 10508 | 10505 | 0.03% | | hash_inline_tests::hash_tuple_4 | 8499 | 8497 | 0.02% | | hash_inline_tests::hash_u128 | 5160 | 5154 | 0.12% | | hash_inline_tests::hash_user_defined_type | 42799 | 42787 | 0.03% | | storage_vec_iter_tests::empty_vec_next_returns_none | 50784 | 50644 | 0.28% | | storage_vec_iter_tests::storage_vec_field_for_loop_iteration | 1574940 | 1573470 | 0.09% | | storage_vec_iter_tests::storage_vec_field_nested_for_loop_iteration | 11570183 | 11559644 | 0.09% | | storage_vec_iter_tests::vec_with_elements_for_loop_iteration | 24015966 | 24011576 | 0.02% | | storage_vec_iter_tests::vec_with_elements_next_returns_element | 24016001 | 24011606 | 0.02% | | u128_inline_tests::parity_u128_log_with_ruint | 1851450 | 1850539 | 0.05% | | u128_inline_tests::revert_u128_zero_root | 232 | 230 | 0.86% | | u128_inline_tests::revert_u128_zero_root_overflow_disabled | 238 | 236 | 0.84% | | u128_inline_tests::u128_log | 24393 | 24391 | 0.01% | | u128_inline_tests::u128_pow | 8902 | 8900 | 0.02% | | u128_inline_tests::u128_root | 13907 | 13872 | 0.25% | | u128_inline_tests::u128_zero_root_unsafe_math | 452 | 450 | 0.44% | | | Improvements | Regressions | | - | -: | -: | | Count | 39 | 2 | | Average | 12.33% | -0.01% | | Median | 0.17% | -0.01% | | Max | 91.56% | -0.01% | | Min | 0.01% | -0.01% | ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > Introduce `__runtime_mem_id`/`__encoding_mem_id` intrinsics and use them to trivially encode/return values, updating ABI entry to `never`, improving gas/binary size, and adjusting docs, IR, and tests. > > - **Core/Compiler**: > - Add intrinsics `__runtime_mem_id<T>() -> u64` and `__encoding_mem_id<T>() -> u64` (AST, semantic, IR gen, const-eval). > - Implement memory-representation modeling and ID hashing (`get_memory_representation`, `get_memory_id`, `get_encoding_representation`/`id`). > - Update ABI entry generation to return `never` and use direct `retd`. > - Extend IR parser/types with `never`. > - **Std Library (`codec.sw`)**: > - `encode<T>`: detect trivially-encodable types (matching IDs) and `memcpy` bytes; otherwise fallback to normal encoding. > - Add `encode_and_return<T>() -> !` using `__contract_ret` for fast returns. > - **Docs**: > - Document `__transmute`, `__runtime_mem_id`, and `__encoding_mem_id` in the Sway book; include constraints/semantics. > - **Tests/Fixtures**: > - Update many snapshots, gas/bytecode expectations, raw log PCs/pointers, and release flags. > - Refresh expected contract IDs in require-deployment tests. > - Notable size/gas reductions across numerous tests; `main_args_empty` shrinks (e.g., 96→64 B) and many gas wins. > - **Misc**: > - Minor utilities (e.g., const-generic length literal extraction) and effect tracking for new intrinsics. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 2caf44cca2. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY --> --------- Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2025-11-18 23:12:49 -03:00
Daniel Frederico Lins Leite	6bca1885f9	Improve method selector on contracts (#7458) ... ## Description This PR continues the optimisation of contract calls on top of https://github.com/FuelLabs/sway/pull/7455. Now the contract method selector is optimised. Ideally, the method selection would just be a `match` and we would let the compiler generate the best code. But we are not there yet. So, for now, we are going to first test the called method length. And based on its length we are going to check the whole string. Something like: ```sway if called_method.len() == 5 { if called_method == "abcde" { ... } if called_method == "fghij" { ... } } if called_method.len() == 10 { if called_method == "..." { .... } } ``` This alone reduces gas a lot. To understand why `match_expressions_all` gas usage is much worse see below. | Test | Before | After | Percentage | |------|--------|-------|------------| | should_pass/empty_fields_in_storage_struct (test.toml)::test_read_write_bytes | 17533 | 12080 | 31.10% | | should_pass/empty_fields_in_storage_struct (test.toml)::test_read_write_map | 13986 | 8502 | 39.21% | | should_pass/empty_fields_in_storage_struct (test.toml)::test_read_write_vec | 29288 | 12797 | 56.31% | | should_pass/language/associated_const_abi (test.toml)::test | 7817 | 4547 | 41.83% | | should_pass/language/associated_const_abi_multiple (test.toml)::test | 2097 | 1511 | 27.94% | | should_pass/language/associated_const_in_decls_of_other_constants (test.toml)::test | 709 | 537 | 24.26% | | should_pass/language/contract_ret_intrinsic (test.toml)::test | 1809 | 1465 | 19.02% | | should_pass/language/match_expressions_all (test.toml) | 764 | 3708 | -385.34% | | should_pass/language/pusha_popa_multiple_defreg (test.toml)::incorrect_pusha_popa | 624 | 451 | 27.72% | | should_pass/language/raw_identifiers (test.error_type.toml)::test | 1075 | 903 | 16.00% | | should_pass/language/raw_identifiers (test.toml)::test | 1075 | 903 | 16.00% | | should_pass/language/references/mutability_of_references_memcpy_bug (test.toml)::test | 1203 | 1031 | 14.30% | | should_pass/language/slice/slice_contract (test.toml)::test_success | 1145 | 920 | 19.65% | | should_pass/language/string_slice/string_slice_contract (test.toml)::test_success | 1322 | 1079 | 18.38% | | should_pass/stdlib/storage_vec_insert (test.toml)::test_test_function | 3831 | 3669 | 4.23% | | should_pass/storage_element_key_modification (test.toml)::test_storage_key_address | 1138 | 943 | 17.14% | | should_pass/storage_element_key_modification (test.toml)::test_storage_key_modification | 757 | 465 | 38.57% | | should_pass/storage_slot_key_calculation (test.toml)::test | 2979 | 2785 | 6.51% | | should_pass/superabi_contract_calls (test.toml)::tests | 1812 | 1310 | 27.70% | | should_pass/superabi_supertrait_external_call (test.toml) | 95 | 76 | 20.00% | | should_pass/superabi_supertrait_same_methods (test.toml)::tests | 936 | 634 | 32.26% | | should_pass/test_abis/abi_impl_methods_callable (test.toml)::tests | 772 | 599 | 22.41% | | should_pass/test_abis/contract_abi-auto_impl (test.toml)::tests | 772 | 599 | 22.41% | | should_pass/unit_tests/aggr_indexing (test.toml)::test1 | 5443 | 4282 | 21.33% | | should_pass/unit_tests/contract-multi-contract-calls (test.toml)::test_contract_2_call | 804 | 631 | 21.52% | | should_pass/unit_tests/contract-multi-contract-calls (test.toml)::test_contract_call | 807 | 634 | 21.44% | | should_pass/unit_tests/contract-multi-contract-calls (test.toml)::test_contract_multi_call | 1592 | 1246 | 21.73% | | should_pass/unit_tests/contract_multi_test (test.toml)::test_fail | 808 | 635 | 21.41% | | should_pass/unit_tests/contract_multi_test (test.toml)::test_success | 806 | 633 | 21.46% | | should_pass/unit_tests/script-contract-calls (test.toml)::test_contract_call | 736 | 563 | 23.51% | | should_pass/unit_tests/workspace_test (test.toml)::test_fail | 808 | 635 | 21.41% | | should_pass/unit_tests/workspace_test (test.toml)::test_success | 807 | 634 | 21.44% | # Radix Trie This PR also turns off the radix trie optimisation at `sway-core/src/semantic_analysis/ast_node/expression/match_expression/typed/typed_match_expression.rs`. I am not 100% sure of its correctness and heuristics. We need a better way to decide when not to use it. One of the examples where the generated code is worse is when all strings are very similar. For example: `get_a` , `get_b`. The generated trie will first test its length. Both have length 5. Not much was gained. Then it tests if for `get_`, which makes sense as it is the common substring. And the last step will test for `a` or `b`. The issue is that all branches and jumps of the last step are not worthy to test just one character. Is probably cheaper to just test the whole string for each option. In the end, we need a better heuristic to determine when to use this optimisation. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2025-11-03 23:06:37 -03:00
Igor Rončević	d6b9a876eb	Fix default --gas-costs option to be built-in (#7475) ... ## Description This PR fixes bug introduced in #7471, where the `built-in` was not properly treated as a default options, and `GasCostsValues::default()` were still used. ## Checklist - [x] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-10-31 00:25:35 +13:00
Igor Rončević	01fc314744	Add --gas-costs option to forc-test and E2E test runner (#7471) ... ## Description This PR adds `--gas-costs` option to `forc-test` and E2E test runner. The option enables providing realistic gas costs to use for gas measurements during executions of tests and/or scripts. The gas costs can be provided from the following sources: - `built-in` Default value. It is hardcode in `forc test` based on the mainnet gas costs at the time of `forc` release. - `mainnet` Fetches the current gas costs from the mainnet using GraphQL. - `testnet` Fetches the current gas costs from the testnet using GraphQL. - `<FILE>` Reads the gas costs from a local JSON file. This PR implements only the `built-in` source and the remaining will be done in a follow up PR that will address #7472. The reason for adding gas costs is that both `forc test` and E2E test runner currently use `GasCosts::default()` when initializing the `Interpreter`. This can lead to very misleading gas cost interpretations. E.g, the default costs of `cfei`, `aloc`, `srwq`, and `swwq` are: ```console cfei: DependentCost::LightOperation { base: 2, units_per_gas: 214, }, aloc: DependentCost::LightOperation { base: 2, units_per_gas: 214, }, srwq: DependentCost::LightOperation { base: 47, units_per_gas: 5, }, swwq: DependentCost::LightOperation { base: 44, units_per_gas: 5, }, ``` Their on-chain costs, taken from the [Chain configuration repository](https://github.com/FuelLabs/chain-configuration/blob/master/upgradelog/ignition/consensus_parameters/6.json), are: ```console "cfei": { "LightOperation": { "base": 2, "units_per_gas": 562 } }, "aloc": { "LightOperation": { "base": 3, "units_per_gas": 562 } }, "srwq": { "HeavyOperation": { "base": 311, "gas_per_unit": 312 } }, "swwq": { "HeavyOperation": { "base": 7838, "gas_per_unit": 8156 } }, ``` The difference between the real on-chain cost and default parameters are significant, especially for `srwq` and `swwq`. In a general case, this difference can make gas usages printed by `forc test` or fetched by E2E `--perf` option very misleading, especially when used to benchmark performance. With the `--gas-costs` option we by default get the realistic, mainnet based built-in cost, and can even specify particular costs we want to have. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-10-30 08:53:28 +11:00
Vaivaswatha N	f92c3f249b	SROA: Do not generate GEPs when direct address is available (#7457) ... Fixes #7433	2025-10-28 12:35:55 +00:00
Igor Rončević	97efa221f0	Excute E2E tests in parallel (#7456) ... ## Description This PR implements parallel execution of E2E tests by using the approach similar to one introduced by @JoshuaBatty for running LSP garbage collection tests in parallel. The approach is based on: - `test` binary getting an additional `--exact` option used by the parallel runner to run exactly one test passed as an argument to `--exact`. The argument is the full path to the test's `toml` file. - parallel runner that uses `rayon` and `std::process::Command` to span `test --exact <test toml path>` processes in parallel. The original command line argument passed to `test` get forwarded to `test --exact` only if they are applicable while running tests in parallel. On my laptop with 20 cores, **the execution time of the complete E2E test suite reduces from reproducible 10:48 minutes to reproducible 1:47 minutes**. Parallel execution is set to be the default one. Sequential execution can still be used via `--sequential` or `-s` flag: `cargo run -- -s` or `test -s`. Similar to parallel garbage collection tests, the parallel execution of E2E tests shows `stderr` output of the executed tests, but not the `stdout`. Being non-deterministic, the position of displayed errors will not come immediately after or before the failing test display, but will always be easy to relate to a concrete failing test. In practice, this will be perfectly enough for troubleshooting failing tests. If all the output is needed during troubleshooting, failing tests can always be executed sequentially, by using the `--sequential` or `-s` flag. Additionally the PR: - adds `no_output` flag to `BuildOpts` to instructs `forc-pkg` not to output build artifacts like bytecode, ABI JSON, or storage slots JSON. This improves test execution speed in general because it skips writing to disc artifacts that are anyhow not used in tests. Also, it simplifies parallelization, because in case of tests with several `test.<feature>.toml` files, we don't need to worry about racing conditions when writing output files. If needed for troubleshooting, output can still be optionally generated in tests by passing the newly added `--write-output` CLI flag to the `test` binary. This flag is ignored when running tests in parallel. A support for the `no_output` option is not added neither to `forc` CLI, nor to CLI of any other tools like, e.g., `forc deploy`. If it proves useful to those tools, we can always easily add it to their CLIs. - fixes #7449 by annotating the `test` binary `main` function with `#[tokio::main(flavor = "current_thread")]`. - renames `exclude_std` CLI option to `no_std_only` to follow the `_only` pattern in naming filters in `FilterConfig` that filter out only the tests with a certain property. Implementing parallel execution for snapshot and IR tests (if required) will be done in followup PRs. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-10-14 10:22:11 +11:00
Igor Rončević	1da5e662e8	Compile runtime backtracing to ASM and compile-time to ABI JSON (#7387) ... ## Description This PR implements the compilation of the ABI backtracking, as described in the [ABI Backtracking RFC](https://github.com/FuelLabs/sway-rfcs/blob/ironcev/abi-backtracing/rfcs/0016-abi-backtracing.md). The PR closes two remaining implementation steps listed in the #7276: - Compile runtime backtracing to ASM and compile-time to ABI JSON - Support backtracing in forc test ### Changes in the ABI JSON and IR Compilation #### `panickingCalls` section in the ABI JSON Each panicking call is identified by a unique number and provided in the new `panickingCalls` section in the ABI JSON. E.g., for this panicking call in a module `some_module` of a package `some_package`: ```sway fn some_function() { let _ = this_function_might_panic(42); } ``` the following ABI JSON entry is created: ```json "panickingCalls": { "1": { "pos": { "function": "some_package::some_module::some_function", "pkg": "some_package@0.1.0", "file": "src/some_module.sw", "line": 4, "column": 8 }, "function": "some_other_package::module::this_function_might_panic" }, } ``` #### Encoding error code and backtrace in a `panic` revert code The generation of the `panic` revert code is changed. A `panic` revert code now encodes: - the information that the revert is generated by a `panic` expression, - the actual error code that can be located in the `errorCodes` section of the ABI JSON, - up to five panicking call IDs, encoded in the order of calling, that can be located in the `panickingCalls` section of the ABI JSON. The encoding of the `u64` revert code works as following: ```console 1_pppppppp_CCCCCCCCCCC_CCCCCCCCCCC_CCCCCCCCCCC_CCCCCCCCCCC_CCCCCCCCCCC ``` - The leading `1` denotes a revert code generated by a `panic` expression. Arbitrary user-defined revert codes will must have the starting bit set to `0` or in other words be less then or equal to `9223372036854775807₁₀ = 7FFFFFFFFFFFFFFF₁₆`. - The `pppppppp` denotes the error code in the `errorCodes` section of the ABI JSON, that identifies the actual `panic` location. - Each `CCCCCCCCCCC` section denotes a panicking call code in the `panickingCalls` section of the ABI JSON. The calls represent the callstack, where the right-most code is the code of the immediate function call in which the `panic` occurs. If all `C`s a zero it means no-call. This will happen if the actual call-depth is less then five calls. #### Calculating backtrace Ever non-entry function that can panic gets an additional function argument: `__backtrace: u64`. The `__backtrace` to pass to a panicking call is calculated at runtime by left-shift the existing `__backtrace` provided by the caller function and append/bitwise OR the unique panicking call ID of the exact panicking call. The ID of that exact panicking call is a compile-time, compiler-generated constant as explained above. The detailed mechanism with examples is provided in the "Runtime execution and bytecode and gas overhead" chapter of the [ABI Backtracking RFC](https://github.com/FuelLabs/sway-rfcs/blob/ironcev/abi-backtracing/rfcs/0016-abi-backtracing.md). ## Additional Changes The `panickingCalls` section of the ABI JSON can differ between `debug` and `release` builds which required adding support for different ABI JSON oracle files in test that `validate_abi`. The requirement to display a fully qualified function name in the panicking call and the backtrace resulted in adding flexibility to displaying functions and types in general. Adjusting affected tests was used as opportunity to remove unnecessary dependencies to the `std` and reduced `std` libraries in a large number of tests. Also, a cleanup is done in some parts of the code, like, e.g., removing code duplications. The PR implements these additional changes: - Implements `TyFunctionDisplay` and `TypeInfoDisplay` for configurable displaying of functions and types. Replacing current various custom implementations of displaying with these two types, mostly in error messages, will be done in separate PRs, with low priority. Also, display might be improved in some edge cases. There are TODOs left in code for such, and improvements will be done in separate PRs, with lower priority. - Displays full type names in warnings and errors, where expected. The PR intentionally temporarily switches to full type names in all errors and warnings by making that a default behavior in `impl DisplayWithEngines for TypeInfo`. This is done so that we can easily spot errors and warnings that should use specific `TyFunctionDisplay` and `TypeInfoDisplay` (tests will break) and adapt those in the follow up PR that will address #7389. That follow up PR will also address usages of type names in LSP. - Implements expressive diagnostics for `CompileError::MethodNotFound` and utilize `TyFunctionDisplay` for displaying all matching candidates. - Implements `Value::new_u64_constant` and removing duplicated code for a common scenario of creating an IR Constant of type `u64`. - Removes several unnecessary `clone()`s and `String` allocations. - Renames fields postfixed with `typeid` to follow more general naming convention for `TypeId` fields and parameters. - Removes unnecessary dependencies to `std` or reduced `std` libraries in tests. - Adds support for different `json_abi_oracle` files for `debug` and `release` build profiles. The `panickingCalls` part of the ABI JSON can vary depending on the build profile. A test that verifies ABI JSON now *must provide* expected oracles for both build profiles, unless a profile is unsupported via `unsupported_profiles` test option. An alternative was considered, to allow just a single oracle file if both `debug` and `release` oracles are the same. The reasoning for having two as mandatory even in that case was to gain more explicit test setup. We can change this upon feedback if needed. The oracles have a suffix of either `.debug.json` or `.release.json` and the name part is, as before, one of the following: - `json_abi_oracle` for obsolete old encoding, - `json_abi_oracle.<experimental feature>` for experimental features, - `json_abi_oracle_new_encoding` for new encoding without other experimental features. - Fixes #7386. - Fixes #7388. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-10-09 08:45:51 +00:00
kaya	5256cd17aa	Revert feat: introduce fuel-telemetry macros (#7295) (#7451) ... ## Description Ran git revert to revert telemetry changes causing #7449 #7450	2025-10-09 19:27:37 +11:00
kaya	35757b6a58	feat: introduce fuel-telemetry macros (#7295) ... ## Description # Add telemetry opt-out support to forc-tracing This adds `fuel-telemetry` to `forc-tracing` with **opt-out functionality** for upstream tools like fuelup. ## Usage First, add it to the `forc-tracing` dependency: ```toml [dependencies] forc-tracing = { version = "0.47", features = ["telemetry"] } ``` Then use the `telemetry::*` glob, followed by the usual `tracing` macros, but with a `_telemetry` postfix: ```rust use forc_tracing::{ init_tracing_subscriber, println_green, println_red, println_yellow, telemetry::*, }; fn main() { init_tracing_subscriber(Default::default()); println_red("Stop"); println_yellow("Slow down"); println_green("Go"); error_telemetry!("Error message for InfluxDB"); warn_telemetry!("Warn message for InfluxDB"); info_telemetry!("Info message for InfluxDB"); debug_telemetry!("Debug message for InfluxDB"); trace_telemetry!("Trace message for InfluxDB"); } ``` This will output the following (note `DEBUG` and `TRACE` messages are filtered out because of `RUST_LOG=info`): ```bash > RUST_LOG=info ./target/debug/example Stop Slow down Go ``` We can then peek into telemetry files like the following: ```bash > cat ~/.fuelup/tmp/*.telemetry.* | while read line; do echo "$line" | base64 -d; echo; done 2025-03-06T19:53:24.923452000Z ERROR aarch64-apple-darwin:Darwin:23.6.0 forc-tracing:0.66.8:src/main.rs 0e3480f5-faab-48b8-a935-21ce90a6f028 auto: Error message for InfluxDB 2025-03-06T19:53:24.925348000Z WARN aarch64-apple-darwin:Darwin:23.6.0 forc-tracing:0.66.8:src/main.rs 0e3480f5-faab-48b8-a935-21ce90a6f028 auto: Warn message for InfluxDB 2025-03-06T19:53:24.925434000Z INFO aarch64-apple-darwin:Darwin:23.6.0 forc-tracing:0.66.8:src/main.rs 0e3480f5-faab-48b8-a935-21ce90a6f028 auto: Info message for InfluxDB 2025-03-06T19:53:31.335690000Z INFO aarch64-apple-darwin:Darwin:23.6.0 systeminfo_watcher:0.1.0:src/systeminfo_watcher.rs ec63b355-7862-47db-9ae3-de0cfcc094c8 poll_systeminfo: cpu_arch="arm64" cpu_brand="Apple M2 Pro" cpu_count=10 global_cpu_usage=15.85 total_memory=34359738368 free_memory=23388143616 free_memory_percentage=0.68 os_long_name="macOS 14.6.1 Sonoma" kernel_version="23.6.0" uptime=2482559 vm="" ci="" load_average_1m=4.52 load_average_5m=4.17 load_average_15m=3.86 ``` ## New: Telemetry Opt-Out Support This PR also adds opt-out functionality for telemetry, allowing upstream tools like fuelup to disable telemetry collection: **Changes:** - Added `--disable-telemetry` CLI flag to main forc binary - Added `FORC_DISABLE_TELEMETRY` environment variable support - Updated all telemetry macros to respect the disable flag - Added `init_telemetry()` function for proper initialization **Opt-out Usage:** ```bash # Disable via CLI flag forc --disable-telemetry build # Disable via environment variable FORC_DISABLE_TELEMETRY=1 forc build # For upstream tools like fuelup export FORC_DISABLE_TELEMETRY=1 fuelup toolchain install latest ``` **Code example with opt-out:** ```rust use forc_tracing::{init_telemetry, init_tracing_subscriber, TracingSubscriberOptions}; fn main() { let options = TracingSubscriberOptions { disable_telemetry: Some(true), ..Default::default() }; init_tracing_subscriber(options.clone()); init_telemetry(&options); // Telemetry macros will now be no-ops when disabled error_telemetry!("This won't be sent to telemetry if disabled"); } ``` The implementation ensures telemetry is opt-out by default but can be easily disabled through either CLI flags or environment variables, making it suitable for upstream tool integration.	2025-10-03 14:22:42 +13:00
kaya	14bb898f3b	chore: bumpt rust version to 1.90 (#7427) ... ## Description Bumping the rust version to 1.90 and fixing the clippy lints along the way	2025-10-02 22:28:51 +13:00
Vaivaswatha N	36d2b12eb1	Skip returning a value when the type is unit (#7401) ... https://github.com/FuelLabs/sway/pull/7381#discussion_r2358242393	2025-09-24 12:22:32 +10:00
Vaivaswatha N	df6839d966	When demoting aggregate returns, no need to return back the new argument pointer (#7381) ... This aids optimizations to perform better. For example https://github.com/IGI-111/blackjack comes down from `22.288 KB` to `21.312 KB`.	2025-09-22 10:10:13 +10:00
Vaivaswatha N	d49cf8e92c	compile string constants to global rather than local memory (#7359) ... In situations such as in the newly added test (taken from the fuels-rs repo), without this change, we end up returning a pointer to local memory.	2025-08-28 20:21:14 +05:30
Igor Rončević	9e98c0e9f6	Apply Clippy's uninlined_format_args lint (#7361) ... ## Description This PR improves the readability of `format!`, `write!`, etc. macros by rolling out the Clippy fixes for the `uninlined_format_args` lint. `cargo clippy` started showing this lint after locally switching to Cargo v1.88.0. Additionally, the PR: - replaces a few occurrences of `io::Error::new(std::io::ErrorKind::Other, <msg>)` with `io::Error::other(<msg>)`. - replaces a single occurrence of `if params.iter().any(|&p| p == "all")` with `if params.contains(&"all")`. ## Checklist - [ ] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-08-27 21:57:48 -03:00
João Matos	8be2dae76b	Implement a command to dump impls for a given type (#7322) ... This adds a new `--dump-impls` CLI command that can be used to dump all the recognized trait impls for a given type name. This also extends the compiler diagnostic system to allow the emission of info diagnostics, as previously we could only emit either warnings of errors, which did not fit this use case. ## Description For example, here is the output of `cargo run --bin forc -- build --path _test-case --dump-impls=std::string::String`: <img width="677" height="958" alt="image" src="https://github.com/user-attachments/assets/42aeca94-bbf9-4dff-8bb3-d1a70000999a" /> And for enums: <img width="642" height="285" alt="image" src="https://github.com/user-attachments/assets/ac565fea-9ebe-4f1d-a9a8-d022617d23d0" /> Closes https://github.com/FuelLabs/sway/issues/7286. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-08-26 16:02:16 -07:00
Vaivaswatha N	05e667dfc9	Remove some uses of ptr_to_int and int_to_ptr, using ptr instead (#7297) ... This is in preparation for the argument mutability analysis. This PR also has some skeleton code for this analysis, but the actual analysis is still a `todo!()`. The analysis will also have better precision if we use fewer asm blocks, but I'll get to that after working on the analysis itself.	2025-08-01 19:22:59 +10:00
Vaivaswatha N	a5e61488da	Represent RawUntypedPtr AST type using a new Pointer IR type (#7272) ... The existing `Pointer` IR type is renamed to `TypedPointer` (to be consistent with the existing `Slice` / `TypedSlice` IR types).	2025-07-22 04:26:38 +00:00
Daniel Frederico Lins Leite	0339852289	Better observability for the compiler (#7250) ... ## Description Whilst finishing "const generics" I spent a LOT of time trying to find why some cases where not working. Until I found the issue on a "indirect input" for the method `type_check_method_application`. The issue is that some other method was returning a wrong value, and although the solution is not hard, there is no way to fix just this problem, and there is no way to assert this returned value to guarantee that the problem will not return. To start to improve these kind of tests, and help debug problems, this PR start to create a "callback" mechanism that allows anyone using the compiler as a library, this will not be available at the CLI, to inspect and control logging. The integration in out e2e test harness is done by the `test.toml`. ``` category = "run" expected_result = { action = "return", value = 1 } expected_result_new_encoding = { action = "return_data", value = "0000000000000001" } validate_abi = true logs = """ if pkg != "std" && event == "on_before_method_resolution" && method == "len_xxx" { print_args(); trace(true); } if pkg != "std" && event == "on_after_method_resolution" && method == "len_xxx" { print_args(); trace(false); } """ ``` The `harness` framework will not call "logs" for every callback that happens outside of the "std" library. To allow interaction with the harness itself, some commands are available: - `print_args` print all the available arguments for that event on the "snapshot"; - `trace` enables/disables trace level logging, that also end up in the "snapshot". In the example above, we will generate the following snapshot: ``` --- source: test/src/e2e_vm_tests/harness_callback_handler.rs assertion_line: 14 --- on_before_method_resolution: FromModule { method_name: len_xxx }; Regular([]); S<unresolved T -> u64, N -> 3> before get_method_safe_to_unify: S<unresolved T -> u64, N -> 3> len_xxx<N -> None>(self: unresolved Self -> S<unresolved T -> T, N -> None>): u64 -> u64 after get_method_safe_to_unify: S<unresolved T -> u64, N -> 3>; len_xxx<N -> 3>(self: unresolved Self -> S<unresolved T -> u64, N -> None>): u64 -> u64 on_after_method_resolution: FromModule { method_name: len_xxx }; Regular([]); S<unresolved T -> u64, N -> 3>; len_xxx<N -> 3>(self: unresolved Self -> S<unresolved T -> u64, N -> None>): u64 -> u64; S<unresolved T -> u64, N -> 3> on_before_method_resolution: FromModule { method_name: len_xxx }; Regular([]); S<unresolved T -> u64, N -> 3> before get_method_safe_to_unify: S<unresolved T -> u64, N -> 3> len_xxx<N -> None>(self: unresolved Self -> S<unresolved T -> T, N -> None>): u64 -> u64 after get_method_safe_to_unify: S<unresolved T -> u64, N -> 3>; len_xxx<N -> 3>(self: unresolved Self -> S<unresolved T -> u64, N -> None>): u64 -> u64 ``` The important part is that the problem I want to fix it's there. On the line of "get_method_safe_to_unify", the "self" parameter const generic argument "N" is not being materialized, although the method resolution pass started with a fully materialized type. With this callback machinery it becomes easier to debug the problems, and possible to generate asserts to internal methods. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers.	2025-07-18 07:24:32 +00:00
Hannes Karppila	74092cbbcd	Subroutine calls using the new JAL instruction (#7085) ... ## Description This PR contains an initial implementtion of subroutine calls using the in-progress [jump-and-link instruction `JAL`](https://github.com/FuelLabs/fuel-specs/pull/630). It substantially reduces the function call overhead: the old code used 4 instructions per call, while the new version uses 1-3 depending on the distance to the called function. ### Future optimizations * Reorder functions, so those that call each other are adjacent * Use absolute or IS-relative jumps where it makes sense, see https://github.com/FuelLabs/sway/issues/7267 ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-07-12 08:23:53 +00:00
Vaivaswatha N	0cae7a3195	treat string array values as if it were [u8; N] (#7258) ... The goal of this PR is to enable the check in the IR verifier to ensure that the operand to `ptr_to_int` instructions can only be pointers. The other changes are to support that.	2025-06-30 19:58:29 +05:30
Hannes Karppila	1ac3514f50	Bump fuel deps (#7228) ... ## Description Bumps fuel-vm, fuel-core fuels-rs and forc-wallet to latest versions. Upgrades Rust to 2021 edition. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - I believe this is non-breaking from user code perspective but I'm not too sure about that - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: z <zees-dev@users.noreply.github.com> Co-authored-by: zees-dev <63374656+zees-dev@users.noreply.github.com> Co-authored-by: JoshuaBatty <joshpbatty@gmail.com> Co-authored-by: IGI-111 <igi-111@protonmail.com>	2025-06-23 13:05:53 +04:00
Vaivaswatha N	776c6cf474	minor adjustment to inliner heuristic (#7232) ... This change reduces the generated code size on our `should_pass` testsuite. Numbers are attached. [should_pass_master.txt](https://github.com/user-attachments/files/20754502/should_pass_master.txt) [should_pass_inliner.txt](https://github.com/user-attachments/files/20754501/should_pass_inliner.txt) --------- Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2025-06-23 06:17:05 +05:30
Vaivaswatha N	e0724422c6	IR: Taking function arg address and representing references as pointers (#6967) ... ## Description This is the third PR to address #6351. It allows safely taking addresses of function arguments, and represents references (`&`) as pointers in the IR. Note: The entire function `type_correction` (in `ir_generation.rs`) and this [edit](2de7ab9ec1 (diff-3b0502f41aeb3c45ddbdb3cc590658d73d2bd7283671eb6d789d7e77a7dd2596R670)) in `compile.rs`, to handle return values, must be removed once we fix and finalize the syntax of references. Until then these two hacks need to stay. Ideally I wanted to put them both in one place (which is the `type_correction` pass), but the return type fix needs to happen, unfortunately, during IR gen. --------- Co-authored-by: IGI-111 <igi-111@protonmail.com> Co-authored-by: Igor Rončević <ironcev@hotmail.com>	2025-06-13 10:12:28 +10:00
Igor Rončević	134916d5b4	Support ABI errors in forc test (#7224) ... ## Description This PR adds support for ABI errors in `forc test`. If a unit test reverts, the received revert code is inspected for known error signals (e.g., coming from `assert`, or `require`) and for ABI errors. Analysis of the received revert code is encapsulated within the `forc_util::tx_utils::RevertInfo` struct implementation. This way, it can be reused between the `forc test` and `forc call`. However, on the long term, this abstraction should be moved to `fuel-abi-types`, because its whole logic is ABI related, and it should also be shareable with the Rust SDK. The reason for temporary placing it within `forc-util` crate is to get the support for ABI errors in `forc test` in the next Sway release, without the need for a new `fuel-abi-types` release that triggers the circular dependency between Sway and Rust SDK repositories. Additionally, the PR unifies the display of test outputs - logs, debug output, and reverts: - for passing tests, none of the output is shown by default, unless specified on the CLI. - for failing tests, all the output is displayed in the "failures" section. - because the `__dbg` output is not a log, a dedicated `--dbgs` CLI argument is added, for all ecal outputs. - because the output of a revert now shows all available information and not only the revert code, the `--revert-codes` CLI argument is renamed to `--reverts`. Closes #7089. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-06-10 06:57:07 +04:00
BlockyJ	ee565f9145	feat: implement forc add and forc remove to add/remove dependencies (#7143) ... ## Description Close #2369 **Summary:** Implements functionality for `forc` to add remove dependencies through cli, similar to Cargo's `add` and `remove` commands. **Work Done:** * ✅ Added `forc add` command to support adding both regular and contract dependencies from path, git, IPFS, or version. * ✅ Implemented conflict checks for version + source collisions (e.g., version + git). * ✅ Added automatic fallback to workspace-relative path for local packages. * ✅ Introduced `forc remove` to cleanly remove specified dependencies from the manifest. * ✅ Modularized update logic using `DepSection` enum for unified regular/contract dependency handling. * ✅ Used `toml_edit` to update the manifest file while preserving formatting. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-05-21 23:47:46 -07:00
Igor Rončević	7386b19846	Remove double IR-compilation of contract methods (#7164) ... ## Description This PR removes the double compilation of contract methods in the IR, in the case of new encoding. The contract methods were first compiled as a part of the compilation of the `__entry` function, and afterwards, again separately. The contract methods compiled in the second compilation pass were later on removed as not reachable. The issue was brought to the surface in a test written by @hal3e in [fuel-rs PR that integrates ABI errors](https://github.com/FuelLabs/fuels-rs/pull/1651). In that particular test, because of the double compilation, a `panic` expression in a contract method got compiled twice and produced two same entries in the ABI JSON. Removing the double compilation resulted in a small reduction of bytecode size and gas usage. In some tests bytecode size got reduced for ~50 bytes and the gas usage for ~30 gas units. Additionally, the PR adjusts the printing of IR global variables, to be the same as printing of configurables and locals, without the spaces between individual entries. ## Checklist - [ ] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-05-12 16:52:58 +00:00
Hannes Karppila	1c885cf0f1	codegen optimization: symbolic fuel-vm interpretation (#7109) ... ## Description This PR adds an initial support to symbolic fuel-vm interpretation to improve codegen. The symbolic execution is designed to be extended in later PRs. In it's current form, it provides three distinct improvements: 1. If a temporary (allocated) register contains a value already held in another register, we can use that other register instead. This reduces register pressure, and removes unnecessary `mov` ops. 2. If a register already has the value we're setting it to, we can eliminate the instruction doing so. 3. For conditional jump instructions, if the value of the condition is known, one of the branches can be elminated. In such cases, the instruction is either removed or replaced with an unconditional jump. Dead code elimination pass can then potentially remove the now-unreachable branch. In addition to these changes, this PR takes the optimization level into account for asm generation. For debug builds, we only run the optimization passes once. But for release builds we run the optimization passes multiple times, until we either cannot eliminate any more operations, or until a fixed upper limit of rounds. For instance, this means that if the new pass added in this PR manages to eliminate a branch, and then dead code elimination removes that code, it could allow the interpretation pass to do even more work. To account for new optimization passes, I also organized them to mulple files, so that the ones which create private types are scoped well and thus easier to read. ## Impact project | size before | size after | size reduction -|-|-|- mira-v1-core | 89.384 KB | 83.480 KB | 6.6% ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). No changes required! - [x] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. Just updated pre-existing ones! - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: Vaivaswatha N <vaivaswatha.nagaraj@fuel.sh> Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2025-05-05 10:50:08 +03:00
Igor Rončević	5f64b96f9c	Implement panic expression (#7073) ... ## Description This PR introduces the `panic` expression to the language, as defined in the [ABI Errors RFC](https://github.com/FuelLabs/sway-rfcs/blob/master/rfcs/0014-abi-errors.md#panic). The `panic` expression can be used without arguments, or accept an argument that implements the `std::marker::Error` trait. The `Error` trait is implemented by the compiler for the unit `()`, string slices, and `#[error_type]` enums. Using the `panic` expression without arguments gives the symetry with the `return` expression and acts in the same way as having unit as an argument. ``` panic; panic (); panic "This is some error."; panic Errors::SomeError(42); ``` Panicking without an argument or with unit as argument is discouraged to use. In the upcoming PR that finalizes the ABI errors feature, we will emit a warning if the `panic` is used without arguments or with unit as argument. `panic` expression is available in all program kinds. In predicates it currently compiles only to revert. Once `__dbg` intrinsic is implemented, we can consider compiling to it in predicates. In the upcoming PR, the `error_codes` entry in the ABI JSON will be available for all program kinds. The dead code analysis for the `panic` expression is implemented in the straightforward way, following the current approach of connecting reverts to the exit node. This will be revisted in a separate PR, together with the open TODOs in the DCA implementation of `Return`. Essentially, we want reverting/panicking to connect to program exit and implicit returns to the exit node. Additionally, the PR: - extends `forc test` CLI attributes with `--revert-codes` that prints revert codes even if tests are successful but revert. - updates outdated "Logs Inside Tests" chapter in the documentation on unit testing. - extends the snapshot testing infrastructure to support `forc test` in snapshot tests. - fixes #7072. Partially addresses #6765. ## Breaking Change `panic` is a new reserved keyword. Once the `error_type` feature becomes integrated, compiling any existing code containing a "panic" as an identifier will result in an "Identifiers cannot be a reserved keyword." error. In this PR, `panic` keyword is hidden behind the `error_type` feature flag. This prevents existing code from breaking, unless opted-in. Note that, although being behind a feature flag, `panic` cannot be used in conditional compilation, means in combination with the `#[cfg(experimental_error_type = true/false)]`. The reason is that `cfg` evaluation happens after parsing, and we can either parse `panic` as a keyword or identifier during the parsing, because we cannot distinguish ambiguous cases like `panic;` or just `panic`. This limitation means, that introducing `panic` to `std` can be done only once the `error_type` feature is fully integrated. In practice, this is not a serious limitation, because introducing `panic` in `std` would anyhow, due to effort and design decisions, happen after the feature is integrated. We will provide a migration for this breaking change that will migrate the existing "panic" identifiers to "r#panic". ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-04-30 20:07:05 +10:00
Daniel Frederico Lins Leite	f736fce7ac	Debug trait and its auto implementation (#7015) ... ## Description This PR implements the `__dbg(...)` intrinsic, which is very similar to Rust `dbg!(...)` macro. Up until now, it has being the norm to use `__log` to debug values. Given that this is NOT the first use case for log, we have always found some issues with it: log does not work on predicates, log does not show "private" fields like `Vec::capacity` and others. To solve these problems `__dbg` is being introduced: 1 - it will work on all program types, including predicates; 2 - it also prints the file name, line and column; 3 - All types will have an automatic implementation of Debug if possible, which can still be customized. 4 - Even `raw_ptr` and other non "loggable" types, have `Debug` impls. 5 - `__dbg` will be completely stripped in the release build by default. It can be turned on again if needed. So this: ``` // Aggregates let _ = __dbg((1u64, 2u64)); let _ = __dbg([1u64, 2u64]); // Structs and Enums let _ = __dbg(S { }); let _ = __dbg(E::None); let _ = __dbg(E::Some(S { })); ``` will generate this: ``` [src/main.sw:19:13] = (1, 2) [src/main.sw:20:13] = [1, 2] [src/main.sw:23:13] = S { } [src/main.sw:24:13] = None [src/main.sw:25:13] = E(S { }) ``` How does this work? `__dbg(value)` intrinsic is desugared into `{ let f = Formatter{}; f.print_str(...); let value = value; value.fmt(f); value }`. `Formatter` is similar to Rust's one. The difference is that we still do not support string formatting, so the `Formatter` has a lot of `print_*` functions. And each `print` function calls a "syscall". This `syscall` uses `ecal` under the hood and it follows unix write syscall schema. ```sway // ssize_t write(int fd, const void buf[.count], size_t count); fn syscall_write(fd: u64, buf: raw_ptr, count: u64) { asm(id: 1000, fd: fd, buf: buf, count: count) { ecal id fd buf count; } } ``` For that to work, the VM interpreter must have its `EcalState` setup and interpret syscall number 1000 as `write`. This PR does this for `forc test` and our `e2e test suite`. Each test in `forc test` will capture these calls and only print to the terminal when requested with the `--log` flag. ## Garbage Collector and auto generated Before, we were associating all auto-generated code with a pseudo file called "&lt;autogenerated&gt;.sw" that was never garbage collected. This generated a problem inside the LSP when the `auto_impl.rs` ran a second time because of a collision in the "shareable type" map. When we try to solve this collision, choosing to keep the old value or to insert the new, the type inside the map points to already collected types and the compiler panics. This is a known problem. The workaround for this is to break the auto-generated code into multiple files. Now they are named "main.autogenerated.sw", for example. We create one pseudo-file for each real file that needs one. When we garbage collect one file, `main.sw`, for example, we also collect its associated auto-generated file. ## Checklist - [ ] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-04-22 07:49:31 -03:00
Daniel Frederico Lins Leite	f607a674e3	More Sway compiler optimizations (#7093) ... ## Description This PR is a prequel to https://github.com/FuelLabs/sway/pull/7015, trying to optimize the compiler to alleviate the hit of having more items, `impl` etc... We have here two optimizations: 1 - We spend a lot of time counting newlines when converting byte offsets to `LineCol`. Now, we calculate line offsets just once, and use binary search later to find which line a byte offset is at. 2 - `QueryEngine::get_programs_cache_entry` was cloning the whole `TyProgram`. That is why `did_change_with_caching` was always getting worse, as the program was increasing in size. Now all compilation stages are behind `Arc`, which makes the `clone` free. ## Analysis Putting a `dbg!(...)` like the image below, and calling `counts` (https://github.com/nnethercote/counts). ``` cargo bench -- traverse 2>&1 | grep "sway-types/src/span.rs:29:9" | counts ```  I get the following results: ``` 972102 counts ( 1) 156720 (16.1%, 16.1%): [sway-types/src/span.rs:29:9] self.pos = 0 ( 2) 15900 ( 1.6%, 17.8%): [sway-types/src/span.rs:29:9] self.pos = 104 ( 3) 15840 ( 1.6%, 19.4%): [sway-types/src/span.rs:29:9] self.pos = 107 ( 4) 2280 ( 0.2%, 19.6%): [sway-types/src/span.rs:29:9] self.pos = 19281 ( 5) 2280 ( 0.2%, 19.9%): [sway-types/src/span.rs:29:9] self.pos = 19285 ( 6) 2280 ( 0.2%, 20.1%): [sway-types/src/span.rs:29:9] self.pos = 19287 ( 7) 2280 ( 0.2%, 20.3%): [sway-types/src/span.rs:29:9] self.pos = 19292 ( 8) 2280 ( 0.2%, 20.6%): [sway-types/src/span.rs:29:9] self.pos = 19323 ( 9) 2280 ( 0.2%, 20.8%): [sway-types/src/span.rs:29:9] self.pos = 19327 ( 10) 2280 ( 0.2%, 21.0%): [sway-types/src/span.rs:29:9] self.pos = 19329 ( 11) 2280 ( 0.2%, 21.3%): [sway-types/src/span.rs:29:9] self.pos = 19334 ( 12) 870 ( 0.1%, 21.4%): [sway-types/src/span.rs:29:9] self.pos = 4285 ... ``` This means that `line_col` is being called 972k times. 16% is for position zero, which should be trivial. The rest will iterate the whole file source code to count number of lines. Making the real complexity of the work here something like `O(qty * self.pos)`. And some values of `self.pos` are not trivial at all. ## Checklist - [ ] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers.	2025-04-21 12:36:15 -07:00
kaya	ba3a0d5635	feat: registry source resolution and builds (#7038) ... ## Description closes #3752, #6903. Adds registry source resolutions and support for building.	2025-04-09 21:09:47 -07:00
BlockyJ	1c68f1c9e0	Add --generate-hexfile flag to forc build for hex-encoded output (#7032) ... close #5017 PR adds new `--generate-hexfile` flag to the `forc build` command, enabling it to output a hex-encoded JSON representation of the compiled binary alongside the `.bin` file. #### ✅ Changes - Added `--generate-hexfile` flag to `forc build`. - Outputs a `.json` file containing the hex-encoded script binary (e.g., `contract-hex.json`). - Ensures bundler compatibility for frontend/SDK consumption. #### 🧪 Example Output ```json { "hex": "0xdeadbeefcafebabe..." } ``` #### 📦 Example Usage ```bash forc build --generate-hexfile ``` Generates: - `contract.bin` (as before) - `contract-hex.json` (new hex representation) ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com> Co-authored-by: zees-dev <63374656+zees-dev@users.noreply.github.com> Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2025-04-08 12:13:13 +00:00
SwayStar123	a5d9d2835f	Merge std and core libraries (#6729) ... ## Description Merges the two libraries. They were initially separate to separate the core logic and fuel vm specific functionality, but that separation is no longer maintained so having a merged library is better. Closes #6708 ## Checklist - [ ] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: Sophie <47993817+sdankel@users.noreply.github.com> Co-authored-by: Igor Rončević <ironcev@hotmail.com>	2025-03-12 23:52:38 +01:00
zees-dev	20973803db	forc-call logs support (#6968) ... ## Description - Added support for viewing emitted logs when making a transaction using forc-call - Added `show_receipts` param (default-false) - so we can optionally prnt out all receipts - The CLI output becomes too long for a call with multiple receipts; this is a minor UI enhancement Addresses https://github.com/FuelLabs/sway/issues/6887 ## Example usage/output ```sway script; struct ExampleParams { test_val: u32, test_str: str, test_tuple: (u32, u64), } fn main() -> u64 { log("hiiii"); log(123); log(ExampleParams { test_val: 5, test_str: "hello world", test_tuple: (1,2) }); 5 } ``` <img width="986" alt="image" src="https://github.com/user-attachments/assets/3725ff17-29c9-43d7-98cc-4cacfc213ecb" /> ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: z <zees-dev@users.noreply.github.com> Co-authored-by: Joshua Batty <joshpbatty@gmail.com> Co-authored-by: kayagokalp <kayagokalp123@gmail.com>	2025-03-01 14:26:16 +13:00
Sophie Dankel	597ecfb6e0	chore: move dev dependencies to workspace (#6966) ... ## Description Moves dev dependencies to the workspace Cargo.toml for consistent versions in tests. Inspired by https://github.com/FuelLabs/sway/pull/6955 ## Checklist - [ ] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers.	2025-02-28 11:44:11 +11:00
Hannes Karppila	37235f2e7d	codegen: Use idiomatic fuel-vm ops for memcpy and addr_of (#6795) ... ## Description SIgnificantly reduces bytecode sizes by transforming the following commonly-used operations when the constant value fits into the immediate part of the `*i` variant of the instruction: * `MOVI(tmp, copy_len); MCP(dst, src, tmp)` → `MCPI(dst, src, copy_len)` (in `compile_mem_copy_bytes`) * `MOVI(dst, offset); ADD(dst, dst, DATA_SECTION)` → `ADDI(dst, DATA_SECTION, offset)` (in `addr_of`) ## Checklist - [ ] I have linked to any relevant issues. (none that I know of) - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). (no changes required) - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. (partially; some values in tests got smaller. we don't seem to be tracking the size and size regressions in tests) - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. (not relevant) - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-01-16 10:49:25 +11:00
Sophie Dankel	6245ee6018	feat: add function for generating bytecode identifier (#6674) ... ## Description Depends on https://github.com/FuelLabs/sway/pull/6522 Related https://github.com/FuelLabs/forc.pub/issues/16 Adds a function, `get_bytecode_id` that generates a sha256 hash of the bytecode with the configurables section of the bytecode removed. This will be used for indexing and lookups of the corresponding ABIs for contracts, predicates, and scripts in the package registry (forc.pub). ## Checklist - [ ] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: Vaivaswatha Nagaraj <vaivaswatha.nagaraj@fuel.sh> Co-authored-by: IGI-111 <igi-111@protonmail.com> Co-authored-by: Marcos Henrich <marcoshenrich@gmail.com> Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2024-11-19 08:49:41 -08:00
Vaivaswatha N	9741809659	Add configurables section offset in the preamble (#6709) ... Re-enabling this feature after a bugfix. (reverted PR: #6522) --------- Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com> Co-authored-by: IGI-111 <igi-111@protonmail.com>	2024-11-18 12:33:47 +05:30
João Matos	6e31144e2b	Profiling support (#6705) ... ## Description This pull request adds the profile feature in the Sway compiler. It communicates with an external `forc-perf` executable in order to signal the beginning and end of different compilation phases for profiling purposes. (re-opening of https://github.com/FuelLabs/sway/pull/6565) ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: Camden Smallwood <camden.smallwood@gmail.com> Co-authored-by: GeorgiosDelkos <georgios.delkos@ourovoros.io> Co-authored-by: IGI-111 <igi-111@protonmail.com>	2024-11-15 00:00:23 +00:00
Kaya Gökalp	ccd86925f9	chore: remove uwuify feature (#6698)	2024-11-06 05:46:40 -08:00
Kaya Gökalp	9c4a339dff	chore: remove unmaintained ansi_term in favor of ansiterm (#6696) ... ## Description related to #2601. Removes ansi_term dependency from sway crates. To remove the dependency completely from dep tree we need a release of sway repo to get a new version of forc_util and use it in forc_wallet as forc_wallet is depending on `forc-util v0.47.0` which uses `ansi_term`. Once that is done we can close #2601	2024-11-06 01:42:25 -08:00
IGI-111	d7dd104dac	Bump to v0.66.4 (#6688)	2024-11-03 17:12:45 +01:00
Vaivaswatha N	3ff63a59c1	EncodeBufferAppend: grow_if_needed should allocate sufficiently (#6686)	2024-11-02 11:47:58 +01:00
Vaivaswatha N	0555973393	Add configurables section offset in the preamble (#6522) ... The preamble now contains 8 bytes of offset to the configurables section. If there is no configurable const in the data-section, then the value of this integer will be equal to the size of the binary itself. This also means that we now sort the data-section to have all the non-configurables first, and then the configurables. The preamble final asm looks like this (the offset to configurables is 0'd out here in the example): ``` ;; ASM: Final program ;; Program kind: Script .program: move $$tmp $pc jmpf $zero i10 DATA_SECTION_OFFSET[0..32] DATA_SECTION_OFFSET[32..64] CONFIGURABLES_OFFSET[0..32] CONFIGURABLES_OFFSET[32..64] lw $$ds $$tmp i1 add $$ds $$ds $$tmp ``` The preamble bytecode looks like this: ``` 0x00000000 MOVE R60 $pc ;; [26, 240, 48, 0] 0x00000004 JMPF $zero 0xa ;; [116, 0, 0, 10] 0x00000008 ;; [0, 0, 0, 0, 0, 0, 2, 40] 0x00000010 ;; [0, 0, 0, 0, 0, 0, 0, 0] 0x00000030 LW R63 R60 0x1 ;; [93, 255, 192, 1] 0x00000034 ADD R63 R63 R60 ;; [16, 255, 255, 0] ... ``` --------- Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com> Co-authored-by: IGI-111 <igi-111@protonmail.com>	2024-10-29 20:16:33 +01:00
Kaya Gökalp	4efd248e36	chore: bump rust version to 1.82 (#6672) ... ## Description Bumps sway version used in CI to v1.82 --------- Co-authored-by: IGI-111 <igi-111@protonmail.com>	2024-10-28 15:41:25 +01:00
Daniel Frederico Lins Leite	ddb505d263	migrate encoding v1 to sway-features (#6586) ... ## Description This PR starts the implementation of https://github.com/FuelLabs/sway-rfcs/blob/master/rfcs/0013-changes-lifecycle.md. ## CLI flags Now, all `CLI`s, including our tests, support two new arguments ``` ... --experimental <EXPERIMENTAL> Comma separated list of all experimental features that will be enabled [possible values: new_encoding, storage_domains] --no-experimental <NO_EXPERIMENTAL> Comma separated list of all experimental features that will be disabled [possible values: new_encoding, storage_domains] ... ``` Experimental features can also be enabled inside `Forc.toml` for workspaces and individual projects. ``` experimental = { encoding-v1 = true } ``` And can be enabled using environment variables: ``` FORC_NO_EXPERIMENTAL=feature_a,feature_b FORC_EXPERIMENTAL=feature_c forc build ... ``` These configurations are applied in a very specific order to allow them to be overwritten. The order from the weakest to the strongest is: 1 - Workspace `TOML` 2 - Project `TOML` 3 - CLI 4 - Environment variables. The rationale is: 1 - We want an easy way to enable and/or disable a feature for the whole workspace; 2 - But we want to allow projects to overwrite these features, when needed. These two are the suggested approach to configure experimental features, but we also want to allow someone to easily turn on or off features to test something in particular. For that one can use the CLI flags; and in the specific case one does not have access to the CLI, for example, when one of the `SDK` is compiling the code, one can still completely overwrite the `TOML` files using environment variables. We are also applying the "no experimental" first. This is to allow the use case of exactly controlling which features will be enabled and disabled. In this case one can use the "meta-feature" `all` to disable everything and enable only the desired features. For example: ``` FORC_NO_EXPERIMENTAL=all FORC_EXPERIMENTAL=new_encoding your_command.... ``` ## Test for "-h" This PR also introduces snapshot tests for "-h" for all forc commands at https://github.com/FuelLabs/sway/pull/6586/files#diff-20a5e677d2ae9266a2247739b6a473d2ad0c627955187d668822e7d194f8e940 ## Multiple test.toml This PR also enables the use of multiple `test.toml`. Now each `test.toml` will be a different test, allowing the same code to be compiled and asserted differently. For example, `main_args_empty` has two files: the normal `test.toml` and a new `test.encoding_v1.toml`. One has `new_encoding` enabled and the other disabled. When a `test.toml` file has the `experimental` field, we do not use fields with `_new_encoding` suffix anymore, making these files simpler: test.toml: ```toml category = "run" # (1336, 1) script_data = "0000000000000538 0000000000000001" expected_result = { action = "return", value = 1337 } validate_abi = true experimental = { encoding_v1 = false } ``` test.encoding_v1.toml ``` script_data = "0000000000000538 0000000000000001" expected_result = { action = "return_data", value = "0000000000000539" } experimental = { new_encoding = true } ``` Test tomls with a suffix use `test.toml` as a base. So we do not need to repeat every field in them. Now when we run a test, we will see two tests instead of just one: ``` ... Testing should_pass/language/main_args/main_args_empty (test.encoding_v1.toml) ... ok Testing should_pass/language/main_args/main_args_empty (test.toml) ... ok ... ``` ## Conditional compilation It is also possible to use conditional compilation using these experimental features. Examples can be found inside `sway-lib-std`. ```sway #[cfg(experimental_new_encoding = true)] pub fn assert_eq<T>(v1: T, v2: T) { ... } ``` ## Checklist - [ ] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: IGI-111 <igi-111@protonmail.com>	2024-10-28 11:34:03 +01:00
Alfie John	e1546f60ee	Version bump the remaining crate dependencies (#6579) ... ## Description As part of #6179, this PR updates the remaining quick-fix crates to their latest X.Y versions. Code fixes were needed to get compilation working and tests passing. Issue #6536 lists the crates that will need a bit more work to get working and passing. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2024-09-23 08:44:31 +02:00
Alfie John	ab1e030f98	Move all crate dependencies to the workspace Cargo.toml (#6179) (#6563) ... ## Description For #6179, PR #6501 kept bumping into errors as it was doing too many things, so I've split that PR into multiple PRs. This is the first, and the only thing it does is move all of the various `Cargo.toml` dependencies into the single workspace `Cargo.toml`. Future PRs will: - Update dependency versions - Update code that breaks from the version bumps ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2024-09-21 09:48:34 +10:00