541 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
Joshua Batty	8103f0d02f	Migrate forc-tracing and forc-crypto to forc monorepo (#7507) ... ## Summary This PR completes the sway-side of migrating `forc-tracing` and `forc-crypto` to the new [forc monorepo](https://github.com/FuelLabs/forc), as outlined in [RFC #49](https://github.com/FuelLabs/sway-rfcs/pull/49). The corresponding forc repo PR: https://github.com/FuelLabs/forc/pull/119 ### Changes - Remove `forc-tracing` crate from workspace (now uses crates.io `0.71.1`) - Remove `forc-crypto` crate from workspace - Update CI to no longer build/package `forc-crypto` binary (it's now built from forc repo) - Update gh-pages workflow to install `forc-crypto` from forc repo for documentation generation ### Distribution Going forward, `forc-crypto` will be built and distributed from the forc repo by: - sway-nightly-binaries - fuelup - fuel.nix ### Documentation For now, documentation for all tooling will continue to live in this repo. The `gh-pages` workflow now pulls `forc-crypto` from the forc repo rather than building it locally, so docs generation continues to work as before.	2025-12-10 08:58:01 +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
zees-dev	936e752176	feat: forc-call abi backtracing (#7502) ... ## Description This PR introduces panic/error traces to the forc call trace output. This functionality is built on top of the existing abi-backtracing introduced in the following: - https://github.com/FuelLabs/sway-rfcs/blob/master/rfcs/0016-abi-backtracing.md - https://github.com/FuelLabs/sway/pull/7224 - https://github.com/FuelLabs/sway/pull/7277 - https://github.com/FuelLabs/fuel-abi-types/pull/36 - https://github.com/FuelLabs/fuel-abi-types/pull/40/files Supplying verbosity level greater than 1 (i.e. `-vv` or `-v=2`) will display the panic/error traces when using `forc-call`. If the called function panics, the panic message and the full backtrace will be displayed in the trace output. ## Example <details> <summary>Example contract code</summary> ```sway contract; abi AbiErrorDemo { #[storage(write)] fn write_non_zero(value: u64); #[storage(read)] fn read_value() -> u64; } storage { value: u64 = 0, } #[error_type] pub enum PanicError { #[error(m = "The provided value must be greater than zero.")] ZeroValue: (), } impl AbiErrorDemo for Contract { #[storage(write)] fn write_non_zero(value: u64) { set_non_zero_value(value); } #[storage(read)] fn read_value() -> u64 { storage.value.read() } } #[trace(always)] #[storage(write)] fn set_non_zero_value(value: u64) { ensure_non_zero(value); storage.value.write(value); } #[trace(always)] fn ensure_non_zero(value: u64) { ensure_non_zero_impl(value); } #[trace(always)] fn ensure_non_zero_impl(value: u64) { if value == 0 { panic PanicError::ZeroValue; } } ``` </details> Example Call: ```sh cargo run -p forc-client --bin forc-call -- \ --abi out/debug/abi_errors-abi.json \ babdc125da45eac42309e60d3aea63a53843f5ff2438d1a88bf8c788e8348c58 \ write_non_zero "0" -vv ``` Example Output: <img width="857" height="340" alt="Screenshot 2025-11-24 at 8 36 00 PM" src="https://github.com/user-attachments/assets/9a14053e-9318-4543-a01a-0d794e30dff2" /> ## 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. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > Adds ABI-aware revert decoding to forc-call, displaying panic messages, values, and backtraces in verbose traces and surfacing revert errors early. > > - **forc-client (call/trace)**: > - Add ABI-aware revert decoding (`RevertInfoSummary`) and integrate into `TraceEvent::Revert`; render panic message, value, location, and backtrace in `display_transaction_trace`. > - New helpers: `decode_revert_info` and `first_revert_info` to extract revert details from receipts and trace. > - `call_function`: generate receipts once, include in interpreter, display detailed info on verbosity, and return an error early when a revert is detected; parse outputs after. > - Minor: reference `trace::display_transaction_trace` directly; extend tests to cover revert detail rendering. > - **forc-util**: > - Add `revert_info_from_receipts` to build `RevertInfo` (revert code, panic metadata) from receipts using optional ABI. > - **forc-test**: > - Replace `revert_code()` with `revert_info()` using new utility; filter by actual revert code; simplify API. > - **Docs**: > - Add "Seeing revert information and backtraces" section with example usage/output for `forc call -vv`. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 957d411acb. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY --> --------- Co-authored-by: z <zees-dev@users.noreply.github.com>	2025-11-26 13:01:36 +04: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
João Matos	6b26e50f09	Update to latest fuels-rs dependency (#7468) ... ## Description Update to latest `fuels-rs` dependency. ## 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. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > Upgrade to latest Fuel/fuels versions and refactor code/tests to new APIs (IDs, receipts, storage, wallet, node owner). > > - **Dependencies**: > - Bump `fuel-core` to `0.47.x`, `fuel-{vm,tx,types,asm,crypto}` to `0.65`, and `fuels{,-core,-accounts}` to `0.76`; update `fuel-core-*` crates across workspace and SDK harness. > - **Core/API migrations**: > - Use `Contract::id(..)` associated function (replaces instance method); update contract ID calculations in `forc-pkg`, `forc-client` deploy, and `forc-test`. > - Adjust receipts handling to `Arc<Vec<_>>` and convert as needed; update parsing/printing of `Receipt::LogData`/`ReturnData` to new byte accessors. > - Update `ContractsStateData` construction and storage conversions in VM trace storage. > - Refactor wallet account collection/types and secret key conversion in tx utils. > - Switch `forc-node` coin owner to `Owner` enum; update logging and tests. > - **Tests**: > - Adapt E2E and client tests to new receipt/data APIs and predicate fee assertions; update SDK harness deps and context tests (ContractIdExt import). > - **Misc**: > - Update workspace `Cargo.toml` and `test/src/sdk-harness/Cargo.toml`; extend `.typos.toml` ignores/excludes. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit d0541bd2ec806d10743310573edde8c85364b4ff. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY -->	2025-11-06 12:51:38 +00:00
João Matos	990a84093a	Add event support via #[event] and #[indexed] attributes (#7158) ... This PR adds two new attributes: `#[event]` and `#[indexed]`. The `#[event]` attribute marks a struct or enum as an event that can be emitted by a contract. The `#[indexed]` attribute can be applied to fields within structs that are attributed with `#[event]`. This is particularly useful for event structs, allowing for efficient filtering and searching of emitted events based on the values of these fields. When using this attribute, the indexed fields must be applied sequentially to the initial set of fields in a struct. This attribute can only be applied to fields whose type is an exact size ABI type. The exact size ABI types include: - `bool` - `u8`, `u16`, `u32`, `u64`, `u256` - `numeric` - `b256` - `str[N]` - Tuples containing only exact size types - Structs containing only exact size types - Arrays of exact size types with a literal length - Type aliases to exact size types Additionally it causes the event types to be included in the JSON ABI representation for the contract and emits an `offset` for indexed fields. ```sway #[event] struct MyEventStruct { #[indexed] id: u64, sender: Identity, } ```	2025-11-05 12:43:59 +01:00
Cameron Carstens	90c8ed2569	Reduce storage API byte allocation (#7430) ... ## Description Legacy functionality from the storage API now allocates more memory than required for the read and write functions. This allocation has been reduced to the correct amounts. Reduces unnecessary byte allocation by 8x. ## 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: Igor Rončević <ironcev@hotmail.com>	2025-11-05 19:45:27 +11:00
Igor Rončević	bfbe49010b	Optimize slot_calculator for bytecode size and gas usage (#7481) ... ## Description This PR optimizes `std::storage_api::slot_calculator` for bytecode size and gas usage by: - skipping calling it if the value fits the slot and the offset is zero, - replacing `match` on a boolean value with `if`. This removes the trailing `else` branch which is present in the desugared `match` expression. - avoiding expensive `.as_u256()` calls and `u256` arithmetic when adding a `u64` to `u256`. ## Performance gains ### Comparing 'e2e-gas-usages': | Test | Before | After | Percentage | |------|-------:|------:|-----------:| | should_pass/empty_fields_in_storage_struct (test.toml)::test_read_write_bytes | 17533 | 16705 | 4.72% | | should_pass/empty_fields_in_storage_struct (test.toml)::test_read_write_map | 13986 | 13526 | 3.29% | | should_pass/empty_fields_in_storage_struct (test.toml)::test_read_write_vec | 29288 | 28187 | 3.76% | | should_pass/language/storage_slot_sized (test.toml)::test_store_something | 10982 | 10247 | 6.69% | | should_pass/stdlib/storage_vec_insert (test.toml)::test_test_function | 3831 | 3102 | 19.03% | | should_pass/test_contracts/basic_storage (test.toml)::collect_basic_storage_contract_gas_usages | 47557 | 42427 | 10.79% | | should_pass/test_contracts/increment_contract (test.toml)::collect_incrementor_contract_gas_usages | 2792 | 2517 | 9.85% | | should_pass/test_contracts/storage_access_contract (test.toml)::collect_storage_access_contract_gas_usages | 162131 | 157884 | 2.62% | | should_pass/test_contracts/storage_enum_contract (test.toml)::collect_storage_enum_contract_gas_usages | 31466 | 23060 | 26.71% | ### Comparing 'e2e-bytecode-sizes': | Test | Before | After | Percentage | |------|-------:|------:|-----------:| | should_pass/empty_fields_in_storage_struct (test.toml) | 11784 | 11616 | 1.43% | | should_pass/language/fallback_only (test.toml) | 1904 | 1552 | 18.49% | | should_pass/language/generics_in_contract (test.toml) | 2336 | 2112 | 9.59% | | should_pass/language/storage_slot_sized (test.toml) | 4864 | 4608 | 5.26% | | should_pass/static_analysis/cei_pattern_violation (test.toml) | 1472 | 1248 | 15.22% | | should_pass/static_analysis/cei_pattern_violation_in_codeblocks_other_than_in_functions (test.toml) | 1704 | 1488 | 12.68% | | should_pass/static_analysis/cei_pattern_violation_in_func_app-1 (test.toml) | 1696 | 1472 | 13.21% | | should_pass/static_analysis/cei_pattern_violation_in_func_app-2 (test.toml) | 1696 | 1472 | 13.21% | | should_pass/static_analysis/cei_pattern_violation_in_func_app-3 (test.toml) | 1696 | 1472 | 13.21% | | should_pass/static_analysis/cei_pattern_violation_in_if_statement-1 (test.toml) | 1720 | 1496 | 13.02% | | should_pass/static_analysis/cei_pattern_violation_in_if_statement-2 (test.toml) | 1696 | 1472 | 13.21% | | should_pass/static_analysis/cei_pattern_violation_in_intrinsic_call (test.toml) | 1696 | 1472 | 13.21% | | should_pass/static_analysis/cei_pattern_violation_in_match_statement-1 (test.toml) | 2200 | 1984 | 9.82% | | should_pass/static_analysis/cei_pattern_violation_in_standalone_function (test.toml) | 1472 | 1248 | 15.22% | | should_pass/static_analysis/cei_pattern_violation_in_struct (test.toml) | 1720 | 1504 | 12.56% | | should_pass/static_analysis/cei_pattern_violation_in_tuple (test.toml) | 1720 | 1504 | 12.56% | | should_pass/static_analysis/cei_pattern_violation_in_while_loop-1 (test.toml) | 1696 | 1472 | 13.21% | | should_pass/static_analysis/cei_pattern_violation_in_while_loop-2 (test.toml) | 1704 | 1480 | 13.15% | | should_pass/static_analysis/cei_pattern_violation_in_while_loop-3 (test.toml) | 1696 | 1472 | 13.21% | | should_pass/static_analysis/cei_pattern_violation_in_while_loop-4 (test.toml) | 1704 | 1480 | 13.15% | | should_pass/static_analysis/cei_pattern_violation_more_complex_logic (test.toml) | 12928 | 12552 | 2.91% | | should_pass/static_analysis/cei_pattern_violation_storage_map_and_vec (test.toml) | 4752 | 4584 | 3.54% | | should_pass/static_analysis/cei_pattern_violation_storage_struct_read (test.toml) | 1720 | 1504 | 12.56% | | should_pass/static_analysis/cei_pattern_violation_storage_var_read (test.toml) | 2072 | 1856 | 10.42% | | should_pass/static_analysis/cei_pattern_violation_storage_var_update (test.toml) | 1608 | 1392 | 13.43% | | should_pass/stdlib/storage_vec_insert (test.toml) | 3264 | 3096 | 5.15% | | should_pass/storage_into (test.toml) | 1688 | 1472 | 12.80% | | should_pass/supertraits_for_abis_ownable (test.toml) | 3440 | 2920 | 15.12% | | should_pass/test_contracts/basic_storage (test.toml) | 29288 | 28184 | 3.77% | | should_pass/test_contracts/increment_contract (test.toml) | 2848 | 2680 | 5.90% | | should_pass/test_contracts/storage_access_contract (test.toml) | 24160 | 23336 | 3.41% | | should_pass/test_contracts/storage_enum_contract (test.toml) | 13440 | 12952 | 3.63% | | should_pass/test_contracts/storage_namespace (test.toml) | 28376 | 27296 | 3.81% | ### Comparing 'in-language-gas-usages': | Test | Before | After | Percentage | |------|-------:|------:|-----------:| | storage_vec_iter_tests::empty_vec_next_returns_none | 55456 | 52550 | 5.24% | | storage_vec_iter_tests::storage_vec_field_for_loop_iteration | 1619781 | 1584251 | 2.19% | | storage_vec_iter_tests::storage_vec_field_nested_for_loop_iteration | 11924960 | 11630896 | 2.47% | | storage_vec_iter_tests::vec_with_elements_for_loop_iteration | 24591048 | 24107244 | 1.97% | | storage_vec_iter_tests::vec_with_elements_next_returns_element | 24586261 | 24104972 | 1.96% | ## 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-11-04 18:56:38 +11: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
Vaivaswatha N	be2d6ae666	Do not read from state when writing aligned, slot sized values (#7470)	2025-10-30 11:41:55 +00: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
Daniel Frederico Lins Leite	7d876d1be6	Improve diff between generic argument generic type argument (#7453) ... ## Description This PR is a continuation of https://github.com/FuelLabs/sway/pull/7391. It also changes from `GenericArgument` to `GenericTypeArgument`. The rationale is that `GenericArgument` should only be used where we can have types and const generics. And it a lot of cases, we only accept types. ## 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. - [ ] 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-20 07:51:33 -03: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
zees-dev	19495ef491	Bump fuel-core v0.46.0 (#7445) ... ## Description Current latest supported mainnet/testnet version of fuel-core is `v0.46.0`; update sway accordingly. ## 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: z <zees-dev@users.noreply.github.com>	2025-10-09 12:35:51 +13:00
zees-dev	8c8a461f30	forc-node wasm32 removal (#7436) ... ## Description - Reconfigure the `forc-node` crate to drop the `wasm-executor` feature - disable fuel-core `default features`; explicit feature-set declaration - `forc-node` `local` CLI configurable args: - DB backend - debug mode - historical execution - PoA trigger directly - Adjust the local-node test harness to cover the newly surfaced CLI knobs. - Remove the `wasm32-unknown-unknown` build target from CI and GitHub Pages workflows. - Regenerate Cargo.lock after the dependency and feature changes. ## 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: z <zees-dev@users.noreply.github.com>	2025-10-03 10:17:49 +04: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
kaya	f502f4a7b7	fix: also create deployment artifacts for chunked deployments (#7426) ... ## Description The deployment artifact generation we have right now was not creating the artifact for chunked deployments. This PR adds that as much as possible as some fields are not expoed via sdk right now (the block height and transaction id) for chunked deployments. Once/if those are exposed we can extend this easily to add those fields as well. But nevertheless this PR serializes majority of the information we have about the chunked deployments to the `out/deployments` folder. --------- Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2025-10-02 06:37:03 +00: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
zees-dev	4f1af4316a	fix: forc-call variable output default estimation with override (#7384) ... ## Description When using `forc-call` with a large `--amount`, the transaction incorrectly sets output count equal to the amount value (e.g., transferring 1000 units creates 1000 outputs). ### Solution - Added `--variable-output` parameter to explicitly control output count - Changed default behavior to estimate minimum outputs via dry-run instead of using using amount value as UTXO outputs - Improved type safety by changing `script_json: serde_json::Value` to `script: fuel_tx::Script` ## Testing - Updated tests to verify correct output counts - Added assertions to check `script.outputs().len()` matches expectations - Tests confirm behavior in both dry-run and live execution modes Addresses: https://github.com/FuelLabs/sway/issues/7383 ## 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. - [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: z <zees-dev@users.noreply.github.com>	2025-09-12 17:36:55 +12:00
Igor Rončević	8fde717752	Add expressive diagnostics for Warning::UnusedReturnValue (#7382) ... ## Description This PR adds expressive diagnostics for the `UnusedReturnValue` warning that explains how to intentionally ignore a returned value by using `let _ = ...`. The reason for adding the diagnostics was an observed confusion among novice Sway developers in the particular case of using `__dbg` intrinsic as a statement: ```sway __dbg("some debug message"); ``` It was unclear to developers why this usage generates the warning, and also how to remove it. Additionally, the PR fixes some `uninlined_format_args` Clippy warnings. ## 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) - [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-09-12 11:19:48 +10:00
Joshua Batty	4552c75917	forc-doc: Preserve all doc links when merging parallel results (#7379) ... ## Description The sway-lib-std docs are broken and not showing all of the generated documentaiton. The root `index.html` was showing only one module while `all.html` listed only a subset of types. This started happening after the parallel processing was introduced in #7296. This PR fixes this as can be seen in the screenshots below. Also undoes the CI changes in #7362 & #7365 as they aren't necessary as this was the root cause. - Root cause: Using BTreeMap::extend to merge per-item results overwrote existing per-category vectors, so only the last chunk from parallel processing survived. - Fix: replace `.extend` merges with per-key append-and-dedup loops. Before: <img width="1608" height="1040" alt="before" src="https://github.com/user-attachments/assets/e433fcc2-cce6-4737-8ed3-c9e2a679de5a" /> After: <img width="1608" height="1040" alt="after" src="https://github.com/user-attachments/assets/c9e9c007-df6a-49b3-b864-e30d19f487f2" /> ## 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-09-11 04:12:48 +00:00
zees-dev	3210f94f05	feat: forc node account funding (#7378) ... ## Description This PR adds support for directly funding accounts when starting a local Fuel node with `forc-node`, eliminating the need to manually edit chainspec files - via specifying `--account` parameter. ## Changes - Added `--account` flag to `forc-node local` command that supports multiple funding formats: - `<account-id>` - funds account with base asset and default amount - `<account-id>:<asset-id>` - funds account with specified asset and default amount - `<account-id>:<asset-id>:<amount>` - funds account with specified asset and amount ## Usage Examples ```bash # Fund single account with default asset and amount forc-node local \ --account 0x54944e5b8189827e470e5a8bacfc6c3667397dc4e1eef7ef3519d16d6d6c6610 # Fund account with custom asset forc-node local \ --account 0x54944e5b8189827e470e5a8bacfc6c3667397dc4e1eef7ef3519d16d6d6c6610:0x0000000000000000000000000000000000000000000000000000000000000002 # Fund account with custom asset and amount forc-node local \ --account 0x54944e5b8189827e470e5a8bacfc6c3667397dc4e1eef7ef3519d16d6d6c6610:0x0000000000000000000000000000000000000000000000000000000000000002:1000000 # Fund multiple accounts forc-node local \ --account 0x54944e5b8189827e470e5a8bacfc6c3667397dc4e1eef7ef3519d16d6d6c6610 \ --account 0xe10f526b192593793b7a1559a391445faba82a1d669e3eb2dcd17f9c121b24b1 ``` ## CLI output <img width="1304" height="254" alt="Screenshot 2025-09-10 at 11 15 41 AM" src="https://github.com/user-attachments/assets/add420e5-a64e-4c82-8605-99aeba7e878a" /> - 5 Initial/funded accounts are provided by forc-node (default 5) - Additional accounts are user provided (optional) - These are introduced in this PR ## Implementation Details - Default amount uses `TESTNET_INITIAL_BALANCE` constant when not specified - Default asset uses the chain's base asset ID when not specified Addresses: https://github.com/FuelLabs/sway/issues/7317 ## 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. - [ ] 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: z <zees-dev@users.noreply.github.com>	2025-09-11 15:36:50 +12:00
zees-dev	1f9880f60d	refactor: forc-node as lib (#7353) ... ## Description This PR fundamentally refactors the `forc-node` plugin architecture by embedding the Fuel Core node directly as an in-process library rather than spawning it as a subprocess. This architectural change modernizes the forc-node plugin and lays the groundwork for advanced local development features. ## 🔄 Changes Overview ### Core Architectural Changes - **In-Process Execution**: Fuel Core now runs within the same process as the plugin, eliminating subprocess management overhead - **Direct Integration**: Replaced subprocess spawning with direct library calls to fuel-core - **Unified Logging**: Consolidated logging and error handling across all execution modes - **Improved Configuration**: Enhanced configuration display and management for better debugging ### Dependency Updates - Added direct fuel-core dependencies - Added fuel-core-chain-config for configuration management - Integrated tracing and tracing-subscriber for improved logging - Updated Cargo.lock with necessary transitive dependencies ## 💡 Motivation ### Current Limitations - Subprocess management adds complexity and potential failure points - Limited ability to extend node functionality - Difficult to implement advanced features like state forking (planned feature) ### Benefits of This Change 1. **Performance**: Eliminates IPC overhead and reduces startup time 2. **Reliability**: Direct function calls are more reliable than subprocess communication 3. **Extensibility**: Easier to add advanced features in future PRs ## 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: z <zees-dev@users.noreply.github.com> Co-authored-by: Joshua Batty <joshpbatty@gmail.com> Co-authored-by: kaya <20915464+kayagokalp@users.noreply.github.com>	2025-09-04 05:02:26 +00:00
Daniel Frederico Lins Leite	6d47ca562e	Iterator trait for arrays (#7370) ... ## Description Continuation of https://github.com/FuelLabs/sway/issues/6860. This PR implements `Iterator` trait for arrays, which allows codes like below: ```sway let array: [u64; 3] = [1u64, 2u64, 3u64]; let mut value = 0; for v in array.iter() { value += v; } assert(value == 6); ``` PS: `#allow` and some unrelated changes demanded by `clippy`. ## 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-09-04 15:10:39 +12:00
zees-dev	ad08f2c5ef	bugfix: forc call explicit support for no external contracts (#7367) ... ## Description Addresses https://github.com/FuelLabs/sway/issues/7366 This pull request updates how external contract addresses are handled in the call command, improving user experience and error handling. The main changes allow: - explicitly indicate when no external contracts should be used - can now explicitly provide no external contracts (which prevents redundant RPC request(s)) using `--external-contracts ''` - users to specify multiple contract IDs in a more flexible format (comma separated string) ## 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. - [ ] 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>	2025-09-03 09:40:50 +12:00
Igor Rončević	84e575ab52	Optimize storage access compilation (#7357) ... ## Description This PR rewrites the compilation of storage accesses via `storage` keyword, e.g. `storage.field`. The new compilation is optimized for gas usage and bytecode size. Some performance comparisons are shown below. When accessing storage, the old compilation was repeatedly constructing the same `StorageKey` as a local variable at each storage access site. E.g., for this example: ```sway storage { scalar: u64 = 0, } impl Contract { #[storage(read)] fn poke_storage() { poke(storage.scalar); } } ``` the resulting IR was: ``` pub entry fn poke_storage() -> (), !4 { local { b256, u64, b256 } __anon_0 local b256 __const = const b256 0x9e0e87bef2e44d9771eb12cfc81e34e4dd6caad55385354757a8898a2c808b61 local b256 __const0 = const b256 0x9e0e87bef2e44d9771eb12cfc81e34e4dd6caad55385354757a8898a2c808b61 local { b256, u64, b256 } __tmp_arg entry(): // BEGIN OF `storage.scalar` ACCESS v0 = get_local ptr b256, __const v1 = get_local ptr b256, __const0 v6 = get_local ptr { b256, u64, b256 }, __anon_0, !5 v7 = const u64 0 v8 = get_elem_ptr v6, ptr b256, v7 mem_copy_val v8, v0 v9 = const u64 1 v10 = get_elem_ptr v6, ptr u64, v9 v11 = const u64 0 store v11 to v10, !5 v12 = const u64 2 v13 = get_elem_ptr v6, ptr b256, v12 mem_copy_val v13, v1 // END OF `storage.scalar` ACCESS v14 = get_local ptr { b256, u64, b256 }, __tmp_arg mem_copy_val v14, v6 v15 = call poke_2(v14) v9 = const unit () ret () v9 ``` The overall cost of each access was: - a local on the stack for each access, `__anon_0` in this case. - two `mem_copy_val`s of the storage slot and field id into that local. - storing the slot offset into that local. The bytecode size cost per access site was significant, but constant, six ASM instructions: ``` load $r0 data_NonConfigurable_0 ; get local constant load $r1 data_NonConfigurable_0 ; get local constant mcpi $$locbase $r0 i32 ; copy memory sw $$locbase $zero i4 ; store word addi $r0 $$locbase i40 ; get offset to aggregate element mcpi $r0 $r1 i32 ; copy memory ``` The gas cost was especially problematic, because a single call site could appear in loops, where the six instructions were repeatedly called. The new implementation stores whole `StorageKey`s into the data section, similar to global constants and configurables. Access sites is then compiled to a single pointer access. The new IR for the above example becomes: ``` contract { storage_key storage.scalar = 0x9e0e87bef2e44d9771eb12cfc81e34e4dd6caad55385354757a8898a2c808b61 pub entry fn poke_storage() -> (), !4 { local { b256, u64, b256 } __tmp_arg entry(): // BEGIN OF `storage.scalar` ACCESS v0 = get_storage_key __ptr { b256, u64, b256 }, storage.scalar, !5 // END OF `storage.scalar` ACCESS v1 = get_local __ptr { b256, u64, b256 }, __tmp_arg mem_copy_val v1, v0 v2 = call poke_2(v1) v9 = const unit () ret () v9 } } ``` And in ASM: ``` addr $r0 data_NonConfigurable_0 ; get storage.scalar's address in data section ``` ## Performance Comparisons The gas savings per storage access will, of course, depend on the number of actual calls. To the bytecode size, the optimization deliberately increases the size of the data section, but only for the case of `StorageKey` slots being equal to field ids. Instead of storing only 32 bytes for a single `b256` address, we are now using 32 + 32 + 8 = 72 bytes for storing the whole `StorageKey`, even if the slot address is the same as field id. That's 40 bytes bytecode increase per storage field. However, we are reducing the storage access for 5 opcodes which results in 5 x 4 = 20 bytes of savings for every storage field access. In other words, if a storage field is accessed more then once anywhere in code, there is no size increase, on the contrary, the bytecode size decreases. This is something we expect in real world programs - storage fields being accessed in more then two places, resulting in bytecode size decrease. ### Bytecode size of `should_pass` tests | Test | Before | After | Percentage | |------|--------|-------|------------| | empty_fields_in_storage_struct | 22528 | 21768 | 3.37% | | language/fallback_only | 2008 | 1944 | 3.19% | | language/generics_in_contract | 2448 | 2400 | 1.96% | | static_analysis/cei_pattern_violation_more_complex_logic | 15392 | 15064 | 2.13% | | static_analysis/cei_pattern_violation_storage_map_and_vec | 6424 | 6224 | 3.11% | | static_analysis/cei_pattern_violation_storage_struct_read | 2784 | 2760 | 0.86% | | static_analysis/cei_pattern_violation_storage_var_read | 2952 | 2928 | 0.81% | | static_analysis/cei_pattern_violation_storage_var_update | 2664 | 2648 | 0.60% | | stdlib/storage_vec_insert | 4864 | 4816 | 0.99% | | storage_slot_key_calculation | 4848 | 4856 | -0.17% | | supertraits_for_abis_ownable | 3576 | 3536 | 1.12% | | test_contracts/basic_storage | 32272 | 31720 | 1.71% | | test_contracts/increment_contract | 3168 | 2984 | 5.81% | | test_contracts/storage_access_contract | 28248 | 26720 | 5.41% | | test_contracts/storage_enum_contract | 16128 | 13736 | 14.83% | | test_contracts/storage_namespace | 31248 | 30648 | 1.92% | The slight bytecode size increase in the `storage_slot_key_calculation` test comes from having exactly one `storage.field` access for every storage field. ### Bytecode size and gas usage of Blackjack project | Test | Before | After | Difference (Gas) | | ---- | ------- | ----- | -------------- | | loss_game_test | 49497 | 49181 | 316 | | simple_game_test | 54123 | 53798 | 325 | The bytecode size decreased from 23320 to 22760 bytes, 560 bytes. ### Gas usage of `storage_vec_iter_tests` | Test | Before | After | Gas | Percentage | |------|--------|-------|-----|------------| | storage_vec_field_for_loop_iteration | 163832 | 162916 | 916 | 0.56% | | storage_vec_field_nested_for_loop_iteration | 1395342 | 1392038 | 3304 | 0.24% | ## 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) - [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-08-29 11:20:40 +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
sashass1315	1412ad3bd1	fix(docs): update Fuel VM instruction set link to new docs site (#7319) ... Replaced outdated GitHub link to the Fuel VM `bhsh` block hash specification with the current link on the official Fuel documentation site. https://docs.fuel.network/docs/specs/fuel-vm/instruction-set/#bhsh-block-hash broken link is https://github.com/FuelLabs/fuel-specs/blob/master/specs/vm/instruction_set.md#bhsh-block-hash Co-authored-by: IGI-111 <igi-111@protonmail.com>	2025-08-22 00:18:51 +00:00
IGI-111	f59835a78a	forc-run debugger integration (#7337) ... ## Description Added a `--debug` flag to `forc run` with the same behavior as `forc call`'s as implemented in #7323. ## 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-08-20 06:52:36 +02:00
zees-dev	6bdfa0c10f	feat: forc-call debugger integration (#7323) ... ## Description This PR adds interactive debugging capabilities to the `forc call` command, enabling developers to debug contract function calls step-by-step after transaction execution. The `--debug` flag is added to the `forc call` command that launches an interactive debugging session after transaction execution. The integration automatically handles transaction/ABI data and launches `forc-debug` for step-by-step debugging. ### Implementation - New `--debug` flag in `forc call` command - `start_debug_session()` function that creates temporary transaction/ABI files and launches the debugger - Integration with existing `forc-debug` functionality via the `start_tx` command ### Usage ```bash forc call 0x0dcba78d7b09a1f77353f51367afd8b8ab94b5b2bb6c9437d9ba9eea47dede97 \ --abi ./contract-abi.json \ get_balance 0x0087675439e10a8351b1d5e4cf9d0ea6da77675623ff6b16470b5e3c58998423 \ --debug ``` This drops users into an interactive debugging session to step through execution, inspect values, and set breakpoints. ### Notes - No breaking changes - feature is additive with optional flag - Temporary files are automatically cleaned up using `tempfile` crate - Zero overhead when `--debug` flag is not used <img width="1070" height="298" alt="image" src="https://github.com/user-attachments/assets/f48e8c7f-063b-4869-b690-810ddb7143cd" /> Addresses https://github.com/FuelLabs/sway/issues/7321. ## 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) - [ ] 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: z <zees-dev@users.noreply.github.com> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>	2025-08-14 16:48:50 +12:00
zees-dev	631f1db3ba	feat: forc-debug as lib (#7320) ... ## Description This PR refactors `forc-debug` from a CLI-only tool into a reusable library while maintaining full backward compatibility with the existing CLI interface. This change enables programmatic debugging capabilities for other tools and plugins in the Sway ecosystem. ### Key Changes **🏗️ Architecture Refactoring** - Extracted core debugging functionality into a `Debugger` struct that can be used as a library - Created structured `DebugCommand` enum to represent all debug operations programmatically - Converted CLI command handlers to use the new library interface internally - Added proper serialization support for commands and responses **📚 New Library API** - `Debugger::new(api_url)` - Create a new debugger instance - `Debugger::execute_command(cmd)` - Execute structured debug commands - `Debugger::execute_from_args(args, output)` - Execute from CLI-style arguments - Comprehensive command types: `StartTransaction`, `SetBreakpoint`, `GetRegisters`, `GetMemory`, etc. **🔄 Backward Compatibility** - All existing CLI commands work exactly as before - No breaking changes to user-facing CLI interface - Command aliases and help system preserved **🧹 Code Quality Improvements** - Removed tight coupling between CLI and debugging logic - Better separation of concerns with clear module boundaries - Improved error handling with structured error types - Enhanced testability through programmatic interface ### Usage Examples **Library Usage:** ```rust use forc_debug::debugger::{Debugger, DebugCommand, AbiMapping}; let mut debugger = Debugger::new("http://localhost:4000").await?; // Start debugging a transaction let cmd = DebugCommand::StartTransaction { tx_path: "transaction.json".to_string(), abi_mappings: vec![AbiMapping::Local { abi_path: "abi.json".to_string() }], }; let response = debugger.execute_command(cmd).await?; ``` **CLI Usage (unchanged):** ```bash forc debug >> tx transaction.json abi.json >> breakpoint 0 >> continue ``` ### Technical Details - **Command Parsing**: Robust parsing of CLI arguments into structured commands with proper error handling - **ABI Management**: Support for both local development ABIs and contract-specific ABI mappings - **Session Management**: Proper lifecycle management of debugging sessions - **Error Propagation**: Structured error types that work well in both library and CLI contexts Addresses: https://github.com/FuelLabs/sway/issues/7315 ## 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. - [ ] 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>	2025-08-13 14:42:41 +12:00
zees-dev	95130c4172	bugfix: forc-call list-functions and script output (#7312) ... ## Description This pull request introduces improvements to ABI (Application Binary Interface) handling in the `forc-client` plugin, focusing on better tracking of ABI sources and minor output consistency fixes. - The `--list-functions` inlined the full string ABI instead of what is provided in the call to the CLI; this results in very large outputs for `--list-functions` call - A fix for the `CallResponse` so that the JSON is `Script` instead of `script` - the capital `Script` is required if we want to pass the response into `forc-debug` Addresses: https://github.com/FuelLabs/sway/issues/7311 ## 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: z <zees-dev@users.noreply.github.com> Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2025-08-08 15:08:41 +12: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
zees-dev	8b29cc39c5	feat: forc-mcp auth for mcp server hosting (#7300) ... ## Description This PR introduces api-key based auth (and management endpoints for an admin account) for the `forc-mcp` HTTP server. Functionality includes: - Admin-only API key management endpoints for creating, listing, viewing, and deleting API keys - Enhanced rate limiting with separate limits for public and authenticated requests - Flexible authentication modes supporting both public access and API-key-only operation The docs have been updated with details on how to add MCP server with auth for claude and cursor. Addresses https://github.com/FuelLabs/sway/issues/7301 <details> <summary>Admin Endpoints</summary> All admin endpoints require authentication with an admin API key via `X-API-Key` header: #### `POST` `/admin/api-keys` - Creates new user-level API keys - Returns the generated API key (shown only once for security) - Generated keys use secure SHA256 hashing with `mcp_` prefix #### `GET` `/admin/api-keys` - Lists all API keys with usage statistics - Optional include_admin=true query parameter to include admin keys - Shows real-time usage counters and rate limit status #### `GET` `/admin/api-keys/{key_id}` - Retrieves details for a specific API key - Returns `404` for admin keys to maintain security - Includes current usage statistics #### `DELETE` `/admin/api-keys/{key_id}` - Deletes specific API keys - Prevents deletion of admin keys (returns 403) - Returns `204` on successful deletion #### `POST` `/admin/import` - Bulk imports API keys with historical usage data - Supports merge mode (default) or replace mode with `clear_existing: true` - Useful for migration or backup restoration </details> ### Dual-Tier Rate Limiting System #### Public Requests (no API key): - Default: `10` requests/minute, `1,000` requests/day - Tracked by client IP address #### Authenticated Requests (with API key): - Default: `120` requests/minute, `10,000` requests/day - Admin keys have unlimited access - Tracked per API key with usage persistence #### Intelligent Counter Reset Logic - Per-minute counters reset after `60` seconds - Daily counters reset at midnight (UTC date change) ### Authentication Modes - Mixed Mode (Default) - Allows both public and authenticated access - Public requests get lower rate limits - API key holders get higher rate limits - API Keys Only Mode - Set `api_keys_only: true` in configuration - Rejects all requests without valid API key - Suitable for production deployments requiring authentication ### Testing - Unit tests for authentication middleware - Integration tests for admin endpoints - Rate limiting validation tests - API key lifecycle tests (create, use, delete) - Security tests (unauthorized access, role escalation) - Persistence tests (file storage, restart recovery) ## 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. --------- Co-authored-by: z <zees-dev@users.noreply.github.com> Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2025-07-31 18:13:37 +12:00
Mike Christopher	688242c07f	feat: check file descriptor limits before running forc node (#7302) ... ## Description Adds a check to try and set the `NOFILE` limit on Unix-based systems. This is important for RocksDB, since we generally exceed the default maximum number of allowed file descriptors allowed by the OS. The idea is to attempt to raise that limit to a reasonable number, and throw an error if we are unable to (likely due to user permission issues). ## 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-07-31 11:31:43 +10:00
Joshua Batty	c7ff31207a	Add parallel processing to forc-doc using rayon to improve performance (#7296) ... ## Description Key changes: - Parallelize document rendering and link generation - Add type aliases for complex nested types (`DocLinkMap`, `ModuleMap`, `RenderResult`) - Remove unnecessary wrapper functions and clones The parallel processing maintains insertion order through sequential merging, ensuring identical documentation output. Not sure why the codspeed report isn't showing this below but when I run `cargo bench` locally i'm seeing these results. | Metric | Before | After | Improvement | |--------|--------|-------|-------------| | build_std_lib_docs | 70.069 ms | 43.227 ms | **43.2% faster** | ## 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-07-30 14:21:46 +04:00
zees-dev	4c9c4c29bf	feat: forc mcp server - with forc-call tool integration (#7284) ... ## Description Introducing Forc-MCP module (CLI). The MCP server can be run in 3 modes: - `stdio` - `sse`: long-running server - using http server-side-events - `http`: long-running server - using http streams ### Forc-call integration The first tool to be integrated is `forc-call` - which exposes the following tool calls: - `list_contract_functions` - `transfer_assets` - `get_execution_trace` - `call_contract` And the following resources: - `MCP Type Encoding Reference` - `MCP Tool Usage Examples` - `Contract Examples with MCP Tools` ### Screenshots from `@modelcontextprotocol/inspector` <img width="2543" height="549" alt="Screenshot 2025-07-15 at 5 09 16 PM" src="https://github.com/user-attachments/assets/aaab5174-d5e6-4685-be71-fd17cd4f5d0f" /> <img width="2540" height="531" alt="Screenshot 2025-07-15 at 5 09 30 PM" src="https://github.com/user-attachments/assets/9ab39d5a-950c-4404-a3a3-6e34b89f58e7" /> ### Example usage (claude code) Pre-requisites: - Run local fuel-core node ``` fuel-core run --ip 127.0.0.1 --port 4000 --db-type rocks-db --debug --historical-execution ``` - Deploy a contract to local node: `forc deploy --default-signer` 1. Run the MCP server (using http-steam in this example): ``` cargo run -p forc-mcp -- http ``` 2. Add mcp server to claude ``` claude mcp add --transport http forc-mcp-http http://localhost:3001/mcp ``` 3. Use claude/LLM to interact with MCP server <details> <summary>Claude output</summary> ``` ╭───────────────────────────────────────────────────╮ │ ✻ Welcome to Claude Code! │ │ │ │ /help for help, /status for your current setup │ │ │ │ cwd: /Users/z/Desktop/fuellabs/sway │ ╰───────────────────────────────────────────────────╯ > Use the forc-mcp-http. Given the following sway contract: demo/demo/src/main.sw deployed at the following address: ae40e8dbe366c5ac61fe558e4e9139300534cd5d9463522621a903464c441eb2 Using the forc-mcp-http: > list all its callable functions. > can you get the current count? > tell me how much gas it would cost to increment the count. > show me the execution trace for incrementing the count. ⎿ ⧉ Selected 14 lines from scratch/ai/templates.md in Cursor ⏺ I'll help you interact with the deployed Sway contract using forc-mcp-http. Let me start by reading the contract to understand its structure, then perform the requested operations. ⏺ Read(demo/demo/src/main.sw) ⎿ Read 34 lines (ctrl+r to expand) ⏺ Now I need to find the ABI file for this contract to use with the forc-mcp-http tools: ⏺ Search(pattern: "demo/demo/out/**/*.json") ⎿ Found 7 files (ctrl+r to expand) ⏺ Perfect! I found the ABI file and a deployment file that matches the contract address. Let me read the ABI: ⏺ Read(demo/demo/out/release/demo-abi.json) ⎿ Read 89 lines (ctrl+r to expand) ⏺ Now let me use the forc-mcp-http tools to interact with the contract. First, I'll list all callable functions: ⏺ forc-mcp-http:list_contract_functions (MCP)(abi: "/demo/demo/out/rele ase/demo-abi.json", contract_id: "ae40e8dbe366c5ac61fe55 8e4e9139300534cd5d9463522621a903464c441eb2") ⎿ Callable functions for contract: ae40e8dbe366c5ac61fe558e4e9139300534cd5d9463522621a903464c441eb2 get_count() -> u64 … +186 lines (ctrl+r to expand) ⏺ Now let me get the current count: ⏺ forc-mcp-http:call_contract (MCP)(abi: "/demo/demo/out/release/demo-a bi.json", contract_id: "ae40e8dbe366c5ac61fe558e4e9139300534cd5d94 63522621a903464c441eb2", function: "get_count") ⎿ { "tx_hash": "0f1e868e75530f33d37748cac9ae25c33bf166c9e02d28e36f3ffdd67ecf3584", "total_gas": 65007, … +354 lines (ctrl+r to expand) ⏺ Now let me check the gas cost for incrementing the count using dry-run mode: ⏺ forc-mcp-http:call_contract (MCP)(abi: "/demo/demo/out/release/demo-a bi.json", contract_id: "ae40e8dbe366c5ac61fe558e4e9139300534cd5d94 63522621a903464c441eb2", function: "increment_count", function_args: ["(1, 2)"], mode: "dry-run") ⎿ Error: Contract call failed: input must start with '{' and end with '}': (1, 2) ⏺ Let me fix the format for the struct argument: ⏺ forc-mcp-http:call_contract (MCP)(abi: "/demo/demo/out/release/demo-a bi.json", contract_id: "ae40e8dbe366c5ac61fe558e4e9139300534cd5d94 63522621a903464c441eb2", function: "increment_count", function_args: ["{\"vals\": [1, 2]}"], mode: "dry-run") ⎿ Error: Contract call failed: input must start with '(' and end with ')': "vals": [1, 2] ⏺ Let me try the tuple format as shown in the example: ⏺ forc-mcp-http:call_contract (MCP)(abi: "/demo/demo/out/release/demo-a bi.json", contract_id: "ae40e8dbe366c5ac61fe558e4e9139300534cd5d94 63522621a903464c441eb2", function: "increment_count", function_args: ["((1, 2))"], mode: "dry-run") ⎿ Error: Contract call failed: input must start with '{' and end with '}': ((1, 2)) ⏺ Let me try with the correct struct format: ⏺ forc-mcp-http:call_contract (MCP)(abi: "/demo/demo/out/release/demo-a bi.json", contract_id: "ae40e8dbe366c5ac61fe558e4e9139300534cd5d94 63522621a903464c441eb2", function: "increment_count", function_args: ["{(1, 2)}"], mode: "dry-run") ⎿ { "tx_hash": "f694c73230e893b00968d8106f5bafbcd585c2cf0f4aea1c6a562ce7e1868690", "total_gas": 78940, … +399 lines (ctrl+r to expand) ⏺ Perfect! Now let me get the execution trace for that increment operation: ⏺ forc-mcp-http:get_execution_trace (MCP)(total_gas: 78940, trace_events: [{"Call":{"index":0,"method ":"increment_count","arguments":["Adder { vals: (1, 2) }"],"to":"ae40e8dbe366c5ac61fe558e4e9139300534cd5d9463522621 a903464c441eb2","amount":0,"gas":26222}},{"LogData":{"index" :2,"id":"ae40e8dbe366c5ac61fe558e4e9139300534cd5d9463522621a 903464c441eb2","value":"3","len":8}},{"ReturnData":{"index": 4,"id":"ae40e8dbe366c5ac61fe558e4e9139300534cd5d9463522621a9 03464c441eb2","data":"()"}},{"Return":{"index":6,"id":"00000 00000000000000000000000000000000000000000000000000000000000" ,"val":1}},{"ScriptResult":{"index":7,"result":"Success","ga s_used":22210}}]) ⎿ Traces: [Script] ├─ [26222] 0xae40e8dbe366c5ac61fe558e4e9139300534cd5d9463522621a903464c441eb2:: … +8 lines (ctrl+r to expand) ⏺ Summary Here are the results for the deployed Sway contract at ae40e8dbe366c5ac61fe558e4e9139300534cd5d9463522621a903464c441eb2: Callable Functions: 1. get_count() → returns u64 (read-only) 3. increment_count(adder: Adder) → returns () (read/write storage) Current Count: The current count is 1 Gas Cost for Increment: Incrementing the count with Adder { vals: (1, 2) } costs 78,940 gas total (22,210 gas used by script) Execution Trace: The increment operation: - Calls increment_count with Adder { vals: (1, 2) } - Uses 26,222 gas for the contract call - Emits a log with value 3 (0 + 1 + 2 = 3, the new count) - Returns () (unit/void) - Total script gas used: 22,210 - Result: Success The contract adds the two values from the Adder struct (1 + 2 = 3) to the current storage count (0) and logs the result. ``` </details> ## 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: z <zees-dev@users.noreply.github.com>	2025-07-24 08:18:31 -07: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
kaya	8963312ba8	feat: add preliminary local checks for forc-publish (#7253) ... ## Description closes #7252. This pull request introduces enhancements to the `forc-publish` plugin, focusing on validating project configurations and improving error handling. Key changes include the addition of a `validate` module for preemptive checks, updates to error definitions, and modifications to the tarball creation logic to incorporate validation. New test cases and sample data directories have also been added to ensure robust validation functionality. ### Validation Enhancements: * Added a new `validate` module in `forc-publish/src/validate.rs` to check for missing `Forc.toml`, missing version fields, and unsupported dependency types. * Updated the `Error` enum in `forc-publish/src/error.rs` to include new error variants for validation failures like `InvalidForcToml`, `MissingVersionField`, and `DependencyMissingVersion`. ### Tarball Creation Updates: * Refactored `create_tarball_from_current_dir` in `forc-publish/src/tarball.rs` to use the new `validate_dir` function for preemptive validation. Removed redundant checks for `Forc.toml` existence. * Adjusted test cases in `forc-publish/src/tarball.rs` to use sample directories with predefined configurations for validation testing. [[1]](diffhunk://#diff-e3f20cadab3a1cf99fc967e0adc12e908f435a185e1529df9b152388927adf45L79-R85) [[2]](diffhunk://#diff-e3f20cadab3a1cf99fc967e0adc12e908f435a185e1529df9b152388927adf45L140-R135) ### Test Data Additions: * Added sample directories under `tests/data` for various validation scenarios, including projects with missing versions, dependencies without versions, and valid configurations. [[1]](diffhunk://#diff-b171d6da23a1fe36735cd962cfcf506831115c3714654236b31dd999c2853823R1-R11) [[2]](diffhunk://#diff-016348eaea4a95d041537b29d370619ab0d5ca99cc84f9b30d8ad561aa757a1eR1-R9) [[3]](diffhunk://#diff-0495f782769450a8c200fdcc1f29805f4811a26f4849720fa34d5b37ba45e471R1-R8) * Included `.gitignore` files in test data directories to exclude `out` and `target` folders.	2025-07-22 02:03:58 +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
Igor Rončević	e303b0f1ab	Add migration for new_hashing (#7287) ... ## Description This PR: - implements "Review existing usages of `StorageMap`, `sha256`, and `keccak256`" migration step for `new_hashing` experimental feature, as described in the Breaking Changes chapter of the tracking issue #7256. - extends the migration infrastructure by providing an optional help message related to an occurrance in code. Instead of returning only `Span`, migration steps now return an `Occurrance` that combine the `Span` with an optional help message. - extends the migration infrastructure to visit all the `TyExpressionVariant`s. For some of the expressions, the typed elements are still not provided. In such cases the migration step for `new_hashing` still detects an occurrence, but the help message lacks the detailed type information. - extends the migration infrastructure to visit all the declarations relevant for the `new_hashing` migration step. E.g.; `trait`, `abi`, and `storage` decls. Additionally, the PR implements `AsRawSlice` for `str`. Here is an excerpt of an output of the migration step run on a test project: ```console info: [new_hashing] Review existing usages of `StorageMap`, `sha256`, and `keccak256` --> /src/test.sw:62:39 | ... 12 | let _ = sha256("affected"); | ---------- info: This has type "str". ... 24 | let user_metadata_key_id = sha256((user_id, key)); | -------------- info: This has type "(b256, String)", that recursively contains "Bytes". | 71 | let _ = sha256_alias(StructCRec::new()); | ----------------- info: This has type "StructCRec", that recursively contains "Vec<u8>". | ::: /src/main.sw:52:5 | ... 13 | let _ = sha256(x); | - info: This has generic type "T". Review all the concrete types used with it. | 39 | directly_affected_str_array: StorageMap<str[3], u64> = StorageMap {}, | --------------------------- info: Review this storage field, because of "str[3]" in "StorageMap" key. | 43 | nested_affected_storage_maps: StorageMap<StructA, StorageMap<raw_slice, StorageMap<EnumARec, StorageVec<StorageMap<str[3], u64>>>>> = StorageMap {}, | ---------------------------- info: Review this storage field, because of "[u8; 0]", "slice", "[u8; 0]", and "str[3]" in "StorageMap" keys. | 52 | metadata: StorageMetadata = StorageMetadata {}, | -------- info: Review this storage field, because of potential custom storage type "StorageMetadata". 56 | 72 | storage.metadata.insert(sha256(handle_name), key, value); | ----------- info: This has type "String", that contains "Bytes". | | = help: New hashing changes the hashes of instances of the following types: = help: - string slices (`str`) = help: - string arrays (`str[N]`) = help: - arrays (`[T; N]`) = help: - raw slices (`raw_slice`) = help: - vectors (`std::vec::Vec<T>`) = help: - bytes (`std::bytes::Bytes`) = help: = help: To decide if opting-in to new hashing is backward-compatible and safe or not, = help: review if those types are directly used, or are contained in types: = help: - used as keys in `StorageMap`s, = help: - used in custom storage types, = help: - hashed using `sha256` or `keccak256` functions. = help: = help: ╔═════════════════════════════════════════════════════════════════════════════════════╗ = help: ║ The above occurrences must not be seen as comprehensive, but rather as a guideline. ║ = help: ║ Carefully review all the storage access and hashing patterns in your code. ║ = help: ║ E.g., using precomputed hashes, having custom `Hash` implementations, and similar. ║ = help: ╚═════════════════════════════════════════════════════════════════════════════════════╝ = help: = help: For a detailed migration guide see: https://github.com/FuelLabs/sway/issues/7256 ``` ## 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-07-18 04:40:36 +00:00
IGI-111	b68a3861db	Bump to v0.69.1 (#7289)	2025-07-17 11:48:56 -07:00