214 commits

Author	SHA1	Message	Date
Vaivaswatha N	ec51769132	Introduce alloc intrinsic to avoid using asm (#7499) ... Improvement chart: https://github.com/FuelLabs/sway/pull/7499#issuecomment-3574549744 --------- Co-authored-by: Igor Rončević <ironcev@hotmail.com>	2025-11-26 10:18:25 +00: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
kaya	d7d5099eae	feat: add support for patching registry dependencies (#7469) ... ## Overview Implements support for patching registry dependencies (from forc.pub) using the `[patch]` table in `Forc.toml`. Previously, only Git dependencies could be patched, which created a workflow gap when packages like `std` migrated from Git to the registry. ## Motivation When `std` and other core packages moved to forc.pub registry, developers lost the ability to: - Test local changes to standard library code - Use unreleased features from development branches - Debug issues with instrumented versions of dependencies This PR restores that capability by extending the existing patch system to support registry packages. ## Implementation ### Key Features 1. **Registry Patching**: Use `[patch.'forc.pub']` to override registry dependencies 2. **Multiple Source Types**: Patch with local path or Git repository 3. **Namespace Support**: Built-in support for namespaced packages (implementation-ready for future use) 4. **Priority System**: Namespace-specific patches override generic patches ## Usage ### Basic Usage ```toml [dependencies] std = "0.70.1" [patch.'forc.pub'] std = { path = "../sway/sway-lib-std" } ``` ### Patch with Git Branch ```toml [dependencies] std = "0.70.1" [patch.'forc.pub'] std = { git = "https://github.com/fuellabs/sway", branch = "my-feature" } ``` ### Workspace-Level Patches ```toml [workspace] members = ["contract-a", "contract-b"] [patch.'forc.pub'] std = { path = "../custom-std" } ``` ## Documentation Updated user documentation in: - `docs/book/src/forc/manifest_reference.md` - Complete patch section rewrite with examples - `docs/book/src/forc/workspaces.md` - Added registry patching examples - Inline code documentation with TOML syntax notes ## Breaking Changes None. This is a purely additive change. All existing Git patches continue to work exactly as before. ## Notes - **TOML Syntax**: Quotes are required: `[patch.'forc.pub']` not `[patch.forc.pub]` - **Source Matching**: Registry patches only apply to registry dependencies - **Namespace Support**: Implementation includes namespace support <!-- CURSOR_SUMMARY --> --- > [!NOTE] > Adds support to patch registry dependencies using `[patch.'forc.pub']` (with namespaced overrides and fallback), keeps Git patching intact, and updates docs with examples. > > - **Core (forc-pkg)**: > - Extend `Source::dep_patch` to handle registry sources: checks `[patch.'forc.pub/<namespace>']` first, then `[patch.'forc.pub']`; Git patching unchanged. > - Add `reg::REGISTRY_PATCH_KEY` constant (`"forc.pub"`). > - **Tests**: > - Add unit tests covering flat/domain namespaces, namespace priority vs. generic fallback, Git patch compatibility, and no-op cases. > - **Docs**: > - Update `docs/book/src/forc/manifest_reference.md` with registry patching examples, notes on quoting keys, and clarifications. > - Update `docs/book/src/forc/workspaces.md` with Git and registry patching examples for workspaces. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 089422addf. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY -->	2025-11-20 00:34:47 -08: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	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
Igor Rončević	a5654fc1af	Add docs for ABI Backtracing (#7435) ... ## Description This PR: - extends the docs on Irrecoverable Errors by explaining the ABI Backtracing. - adds docs for the `#[trace]` attribute. - adds docs for the `backtrace` build option. It is the final step in implementing the #7276. ## Checklist - [x] I have linked to any relevant issues. - [ ] 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) - [ ] 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-11 18:31:58 +11:00
Igor Rončević	77190d15fc	Add "Experimental Features" chapter to The Sway Book (#7416) ... ## Description This PR adds "Experimental Features" chapter to The Sway Book. #7256 will likely create need for some developers to actively use experimental features as a part of their project configurations, or CI. It was already reported that it's unclear how to add experimental features in the `Forc.toml`, and the [RFC chapter on enabling features in Sway](https://github.com/FuelLabs/sway-rfcs/blob/master/rfcs/0013-changes-lifecycle.md#enabling-features-on-sway) is unfortunately outdated. Also, some of the possibilities listed in the RFC are currently not implemented, like, e.g., the meta token for enabling and disabling all experimental features. This PR documents the actually implemented way of using experimental features. Additionally, it fixes the index page of the "Sway Reference" chapter, by listing all the sub-chapters in the right order. ## Checklist - [x] I have linked to any relevant issues. - [ ] 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.	2025-09-26 07:58:27 -03:00
kaya	c58ddbc57f	docs: improve docs around proxy contract deployments (#7352) ... ## Description closes #7351 Improved documentation for the proxy contract feature in forc-deploy. The existing documentation was basic and lacked comprehensive details about the deployment process, configuration options, and usage scenarios. This update provides: - Detailed explanation of proxy contract purpose and benefits - Complete configuration reference with field descriptions - Step-by-step deployment workflows for both fresh and existing proxy scenarios - Real deployment output examples - Transaction details and storage slot handling information - Important security and compatibility notes The enhanced documentation helps users understand and effectively use the proxy feature for upgradeable contracts while maintaining consistency with the existing documentation style.A ## Checklist - [x] I have linked to any relevant issues. - [ ] 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) - [ ] 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-09-03 14:58:43 +12: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
Galoretka	a4274c1fa2	chore: fix broken link in libraries.md (#7309) ... Replaced broken link https://github.com/FuelLabs/sway-libs/tree/master/libs/src/signed_integers with the correct one https://docs.fuel.network/docs/sway-libs/signed_integers/	2025-08-05 12:17:48 +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
MozirDmitriy	32dcbaa243	docs: fix broken sway-libs GitHub link to use official documentation URL (#7298) ... - Replace https://github.com/FuelLabs/sway-libs/tree/master/libs/src/ownership with https://fuellabs.github.io/sway-libs/book/ownership/index.html	2025-07-28 19:51:33 -07: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
João Matos	f117e855ea	Add #[abi_name(name = "foo")] attribute to rename ABI items. (#7057) ... ## Description Add `#[abi_name(name = "foo")]` attribute to rename enum and struct ABI items. Here is example of how it can be used: ```sway contract; #[abi_name(name = "RenamedMyStruct")] struct MyStruct {} #[abi_name(name = "RenamedMyEnum")] enum MyEnum { A: () } abi MyAbi { fn my_struct() -> MyStruct; fn my_enum() -> MyEnum; } impl MyAbi for Contract { fn my_struct() -> MyStruct { MyStruct{} } fn my_enum() -> MyEnum { MyEnum::A } } ``` Closes https://github.com/FuelLabs/sway/issues/5955. ## Remarks The checking for ABI names is being done in the ABI generation phase, which made it a requirement to change the interface of ABI checking to return Results everywhere and passing Handler all the way down, so emitted errors can be passed down to the driver for reporting. ## 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: IGI-111 <igi-111@protonmail.com>	2025-07-17 20:12:36 -07:00
Daniel Frederico Lins Leite	384f46f61d	Contract self impl (#7275) ... ## Description Continuation of https://github.com/FuelLabs/sway/pull/7030. ## 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: hey-ewan <ewanretorokugbe@gmail.com> Co-authored-by: ewan ✦ <66304707+hey-ewan@users.noreply.github.com> Co-authored-by: IGI-111 <igi-111@protonmail.com>	2025-07-11 11:02:37 +00:00
zees-dev	0ac606c132	forc-call detailed vm-interpreter call traces (#7251) ... ## Description This PR updates the `forc call` functionality to provide detailed call traces. This is achieved via retrieving `Vec<StorageReadReplayEvent>` from transactions (dry-run and/or live mode) and executing these in a vm-interpreter. - The approach is inspired by code snippets from this repo: https://github.com/FuelLabs/execution-trace ### Additional `forc-call` updates: - introduction of contract address labelling via `--label <contract-addr>:<name>` - introduction of providing additional contract abis via `--contract-abi <contract-addr>:<abi-file-or-url>` #### Example Assume the following 2 contracts - where `demo-caller` calls `demo` contract: - `demo`: `0xe84e278cb083a5b3ff871f1d3de26fdd13ae044070e1bbda18b60a13f98bb295` - `demo-caller`: `0xed4437b191cc78a02df048f21a73df37f1627efdde7d7e4232468b9de9d83485` <details> <summary>demo contract source</summary> ```sway contract; use std::{logging::log}; struct Adder { vals: (u64, u64), } abi Demo { #[storage(read)] fn get_count() -> u64; #[storage(read, write)] fn increment_count(adder: Adder); } storage { count: u64 = 0, } impl Demo for Contract { #[storage(read)] fn get_count() -> u64 { storage.count.read() + 1 } #[storage(read, write)] fn increment_count(adder: Adder) { let new_count = storage.count.read() + adder.vals.0 + adder.vals.1; storage.count.write(new_count); log(new_count); } } ``` </details> <details> <summary>demo-caller contract source</summary> ```sway contract; use std::contract_id::ContractId; struct Adder { vals: (u64, u64), } abi Demo { #[storage(read)] fn get_count() -> u64; #[storage(read, write)] fn increment_count(adder: Adder); } abi DemoCaller { #[storage(read, write)] fn call_increment_count(adder: Adder) -> u64; #[storage(read)] fn check_current_count() -> u64; } const CONTRACT_ID = 0xe84e278cb083a5b3ff871f1d3de26fdd13ae044070e1bbda18b60a13f98bb295; impl DemoCaller for Contract { #[storage(read, write)] fn call_increment_count(adder: Adder) -> u64 { let demo = abi(Demo, CONTRACT_ID); demo.increment_count(adder); log("incremented count"); log(demo.get_count()); log("done"); demo.increment_count(Adder { vals: (5, 2) }); demo.get_count() } #[storage(read)] fn check_current_count() -> u64 { let demo = abi(Demo, CONTRACT_ID); demo.get_count() } } ``` </details> **Previous functionality**: ```sh cargo run -p forc-client --bin forc-call -- \ --abi ./demo/demo-caller/out/release/demo-caller-abi.json \ ed4437b191cc78a02df048f21a73df37f1627efdde7d7e4232468b9de9d83485 \ call_increment_count "{(1,1)}" -vvv ``` **Output**: <img width="721" alt="Screenshot 2025-06-24 at 12 14 53 PM" src="https://github.com/user-attachments/assets/2ef77293-54eb-46c3-989a-b7f8cf9d236c" /> **Updated functionality**: ```sh cargo run -p forc-client --bin forc-call -- \ --abi ./demo/demo-caller/out/release/demo-caller-abi.json \ ed4437b191cc78a02df048f21a73df37f1627efdde7d7e4232468b9de9d83485 \ --contract-abi e84e278cb083a5b3ff871f1d3de26fdd13ae044070e1bbda18b60a13f98bb295:./demo/demo/out/release/demo-abi.json \ --label ed4437b191cc78a02df048f21a73df37f1627efdde7d7e4232468b9de9d83485:demo-caller \ --label e84e278cb083a5b3ff871f1d3de26fdd13ae044070e1bbda18b60a13f98bb295:demo \ call_increment_count "{(1,1)}" -vv ``` **Output**: <img width="760" alt="Screenshot 2025-06-24 at 12 15 25 PM" src="https://github.com/user-attachments/assets/442c0a97-80f8-46b6-bdf9-d67952c28b58" /> ### Other misc. improvements to `forc-call` - refactor of the forc-call verbosity levels and functions (arguably cleaner code) - re-write of the tracing to simply process receipts and indent via stack - instead of recursively constructing node-call tree - closes https://github.com/FuelLabs/sway/issues/7197 ## AI description This pull request introduces significant enhancements to the `forc call` functionality, improving usability, debugging, and trace readability for multi-contract interactions. The changes include support for labeled contract addresses, additional ABI files for better decoding, and updates to verbosity levels. Additionally, dependencies and internal parsing logic have been updated to support these features. ### Enhancements to `forc call` functionality: * **Support for labeled contract addresses:** - Added the `--label` flag to allow users to assign human-readable labels to contract addresses in transaction traces, improving readability. [[1]](diffhunk://#diff-466e2f9659cab303594eb73a846768ecdbc1a13030e5869cdac51ddde87dd313R289-R302) [[2]](diffhunk://#diff-4ee92d729fce66f7e7aed1fc29b41834951eb63198e0da747b9b9e45d13f717bR248-R320) - Updated documentation to include examples of using labels in traces. [[1]](diffhunk://#diff-4ee92d729fce66f7e7aed1fc29b41834951eb63198e0da747b9b9e45d13f717bR63-R73) [[2]](diffhunk://#diff-466e2f9659cab303594eb73a846768ecdbc1a13030e5869cdac51ddde87dd313R184-R193) * **Support for additional ABIs:** - Introduced the `--contract-abi` flag to specify additional contract ABIs for decoding function signatures, parameters, and return values in multi-contract interactions. [[1]](diffhunk://#diff-466e2f9659cab303594eb73a846768ecdbc1a13030e5869cdac51ddde87dd313R289-R302) [[2]](diffhunk://#diff-466e2f9659cab303594eb73a846768ecdbc1a13030e5869cdac51ddde87dd313R209-R217) - Updated the parsing logic to handle additional ABIs and labels. - Documentation now includes examples and explanations for using additional ABIs. [[1]](diffhunk://#diff-4ee92d729fce66f7e7aed1fc29b41834951eb63198e0da747b9b9e45d13f717bR102-R115) [[2]](diffhunk://#diff-4ee92d729fce66f7e7aed1fc29b41834951eb63198e0da747b9b9e45d13f717bR248-R320) * **Improved verbosity and tracing:** - Adjusted verbosity levels to make transaction traces available at `-vv` instead of `-vvv`. - Enhanced trace output to include labeled contract addresses and decoded function information. [[1]](diffhunk://#diff-4ee92d729fce66f7e7aed1fc29b41834951eb63198e0da747b9b9e45d13f717bL253-R333) [[2]](diffhunk://#diff-4ee92d729fce66f7e7aed1fc29b41834951eb63198e0da747b9b9e45d13f717bR357-R413) ### Dependency and internal updates: * **Dependency additions:** - Added `fuel-core-storage` as a dependency in `Cargo.toml` to support new features. [[1]](diffhunk://#diff-2e9d962a08321605940b5a657135052fbcef87b5e360662bb527c96d9a615542R93) [[2]](diffhunk://#diff-f0f5128eecb15714bd0a80d1f03d87a84f375d0598471bb27e3bb388c188550cR49) * **Parsing and execution logic:** - Refactored `forc-client` to include reusable functions for parsing ABIs and labels. - Updated the `call_function` logic to handle additional ABIs and integrate with the new dry-run execution method. [[1]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeR54-R64) [[2]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeL137-R172) ## Checklist - [ ] I have linked to any relevant issues. - [ x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] 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: kaya <20915464+kayagokalp@users.noreply.github.com>	2025-06-30 19:14:25 +12:00
Joshua Batty	c37dc92952	remove archived forc-explore plugin from CI and docs (#7257) ... ## Description This repo was [archived ](https://github.com/FuelLabs/forc-explorer )in July 2024 but was not removed from CI or the docs. I have update the plugins section of the documentation from forc explore to `forc-install` which is a [tool](https://github.com/DarthBenro008/forc-install) from a community member. ## Checklist - [x] I have linked to any relevant issues. - [ ] 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.	2025-06-27 12:53:25 +00:00
Vaivaswatha N	586a968ef1	support __addr_of for all types (#7255)	2025-06-27 15:33:42 +12:00
Igor Rončević	3b5e7a8d9b	Add docs for error handling (ABI errors, panic, error_type, error) (#7249) ... ## Description This PR: - Adds a new "Error handling" page to "Sway Language Basics". - Updates all references to ABI errors. - Extends the "Breaking Release Checklist" with documentation related checks. ## Checklist - [ ] I have linked to any relevant issues. - [ ] 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.	2025-06-23 13:15:50 +00:00
VolodymyrBg	83154ab661	Update Merkle library link to current documentation (#7244) ... Replaced the outdated GitHub link to the Binary Merkle Proof library with the up-to-date documentation link at https://docs.fuel.network/docs/sway-libs/merkle/. This ensures users have access to the latest usage instructions and examples.	2025-06-22 03:43:10 +04:00
Cameron Carstens	d6804729c9	Introduce the Time Library (#7206) ... ## Description This PR introduces a comprehensive UNIX time handling library to the Sway standard library, providing essential time manipulation capabilities for smart contracts. Time operations are fundamental for many smart contract use cases: - Token vesting schedules - Auction deadlines - Time-locked transactions - Subscription renewals - Staking periods Currently, Sway lacks standardized time utilities, forcing developers to: - Handle time conversions manually - Implement custom time logic in every contract - Risk errors in critical time calculations This library solves these problems with a robust, well-tested time abstraction. ### Duration Handling ```sway // Create durations using natural units let lock_period = Duration::days(90); let auction_extension = Duration::minutes(15); // Convert between units log(lock_period.as_weeks()); // ≈12.857 weeks log(auction_extension.as_seconds()); // 900 seconds // Duration arithmetic let total_lock = lock_period + Duration::weeks(2); ``` ### Blockchain Time Operations ```sway // Get current block time let now = Time::now(); // Create future/past timestamps let unlock_time = now.add(Duration::days(30)); let vesting_start = now.subtract(Duration::weeks(12)); // Measure time differences let time_elapsed = now.duration_since(vesting_start).unwrap(); ``` ### TAI64 ↔ UNIX Conversion Support for the existing TAI64 `timestamp()` functionality is maintained. ```sway // Native TAI64 from blockchain let tai_timestamp = timestamp(); // Convert to UNIX time let unix_time = Time::from_tai64(tai_timestamp); // Convert back to TAI64 let converted_tai = unix_time.as_tai64(); assert(tai_timestamp == converted_tai); ``` ### Benefits - Safety: Prevents common time calculation errors - Accuracy: Properly handles TAI64/UNIX conversion - Productivity: Reduces boilerplate for time operations - Consistency: Standardized approach across contracts - Readability: Natural time unit expressions ### Future Extensions Once support between different types for `Add`, `Subtract`, `Multiply`, etc are implemented, we may be able to do the following: ```sway let now = Time::now(); let future = now + Duration::DAY; let three_weeks = Duration::WEEK * 3; ``` Closes https://github.com/FuelLabs/sway/issues/3945 ## 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.	2025-05-30 19:03:23 +10:00
zees-dev	a2f88d041c	feat: forc call tracing (#7196) ... ## Description Resolves https://github.com/FuelLabs/sway/issues/6706 Introduces `forc-call` transaction tracing - for verbosity levels `3+` (`-v=3` or `-vvv`). The tracing primarily utilizes transaction receipts, generating a call tree structure, then rendering this tree to `stdout`. Example usage output: ```sh > forc-call --abi ./demo/demo-caller/out/release/demo-caller-abi.json 9275a76531bce733cfafdbcb6727ea533ebbdc358d685152169b3c4eaa47b965 call_increment_count -vvv ``` <img width="629" alt="image" src="https://github.com/user-attachments/assets/6ad73c2a-a08e-4829-8d46-0b951e9b723b" /> <details> <summary>Output receipts for the trace above</summary> ```json { "receipts": [ { "Call": { "id": "0000000000000000000000000000000000000000000000000000000000000000", "to": "9275a76531bce733cfafdbcb6727ea533ebbdc358d685152169b3c4eaa47b965", "amount": 0, "asset_id": "f8f8b6283d7fa5b672b530cbb84fcccb4ff8dc40f8176ef4544ddb1f1952ad07", "gas": 124116, "param1": 10480, "param2": 10508, "pc": 11928, "is": 11928 } }, { "Call": { "id": "9275a76531bce733cfafdbcb6727ea533ebbdc358d685152169b3c4eaa47b965", "to": "b792b1e233a2c06bccec611711acc3bb61bdcb28f16abdde86d1478ee02f6e42", "amount": 0, "asset_id": "0000000000000000000000000000000000000000000000000000000000000000", "gas": 111500, "param1": 67107840, "param2": 67106816, "pc": 19064, "is": 19064 } }, { "ReturnData": { "id": "b792b1e233a2c06bccec611711acc3bb61bdcb28f16abdde86d1478ee02f6e42", "ptr": 0, "len": 0, "digest": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", "pc": 21004, "is": 19064, "data": [] } }, { "LogData": { "id": "9275a76531bce733cfafdbcb6727ea533ebbdc358d685152169b3c4eaa47b965", "ra": 0, "rb": 10098701174489624218, "ptr": 67104256, "len": 25, "digest": "392232ec5cf9a0ef3c155ad19684907344847572e913a7a374d703fb9c9d8b5d", "pc": 15804, "is": 11928, "data": [ 0, 0, 0, 0, 0, 0, 0, 17, 105, 110, 99, 114, 101, 109, 101, 110, 116, 101, 100, 32, 99, 111, 117, 110, 116 ] } }, { "Call": { "id": "9275a76531bce733cfafdbcb6727ea533ebbdc358d685152169b3c4eaa47b965", "to": "b792b1e233a2c06bccec611711acc3bb61bdcb28f16abdde86d1478ee02f6e42", "amount": 0, "asset_id": "0000000000000000000000000000000000000000000000000000000000000000", "gas": 86284, "param1": 67103232, "param2": 67102208, "pc": 19072, "is": 19072 } }, { "ReturnData": { "id": "b792b1e233a2c06bccec611711acc3bb61bdcb28f16abdde86d1478ee02f6e42", "ptr": 67099904, "len": 8, "digest": "cd04a4754498e06db5a13c5f371f1f04ff6d2470f24aa9bd886540e5dce77f70", "pc": 21352, "is": 19072, "data": [ 0, 0, 0, 0, 0, 0, 0, 2 ] } }, { "LogData": { "id": "9275a76531bce733cfafdbcb6727ea533ebbdc358d685152169b3c4eaa47b965", "ra": 0, "rb": 1515152261580153489, "ptr": 67098880, "len": 8, "digest": "cd04a4754498e06db5a13c5f371f1f04ff6d2470f24aa9bd886540e5dce77f70", "pc": 15976, "is": 11928, "data": [ 0, 0, 0, 0, 0, 0, 0, 2 ] } }, { "LogData": { "id": "9275a76531bce733cfafdbcb6727ea533ebbdc358d685152169b3c4eaa47b965", "ra": 0, "rb": 10098701174489624218, "ptr": 67097856, "len": 12, "digest": "a3d2743e2a3ab241ba31ffc7133a43daabe6a8e624c7edc92410068a3896c871", "pc": 16072, "is": 11928, "data": [ 0, 0, 0, 0, 0, 0, 0, 4, 100, 111, 110, 101 ] } }, { "Call": { "id": "9275a76531bce733cfafdbcb6727ea533ebbdc358d685152169b3c4eaa47b965", "to": "b792b1e233a2c06bccec611711acc3bb61bdcb28f16abdde86d1478ee02f6e42", "amount": 0, "asset_id": "0000000000000000000000000000000000000000000000000000000000000000", "gas": 72699, "param1": 67096832, "param2": 67095808, "pc": 19064, "is": 19064 } }, { "ReturnData": { "id": "b792b1e233a2c06bccec611711acc3bb61bdcb28f16abdde86d1478ee02f6e42", "ptr": 0, "len": 0, "digest": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", "pc": 21004, "is": 19064, "data": [] } }, { "Call": { "id": "9275a76531bce733cfafdbcb6727ea533ebbdc358d685152169b3c4eaa47b965", "to": "b792b1e233a2c06bccec611711acc3bb61bdcb28f16abdde86d1478ee02f6e42", "amount": 0, "asset_id": "0000000000000000000000000000000000000000000000000000000000000000", "gas": 48287, "param1": 67093248, "param2": 67092224, "pc": 19072, "is": 19072 } }, { "ReturnData": { "id": "b792b1e233a2c06bccec611711acc3bb61bdcb28f16abdde86d1478ee02f6e42", "ptr": 67089920, "len": 8, "digest": "d5688a52d55a02ec4aea5ec1eadfffe1c9e0ee6a4ddbe2377f98326d42dfc975", "pc": 21352, "is": 19072, "data": [ 0, 0, 0, 0, 0, 0, 0, 3 ] } }, { "ReturnData": { "id": "9275a76531bce733cfafdbcb6727ea533ebbdc358d685152169b3c4eaa47b965", "ptr": 67088896, "len": 8, "digest": "d5688a52d55a02ec4aea5ec1eadfffe1c9e0ee6a4ddbe2377f98326d42dfc975", "pc": 12608, "is": 11928, "data": [ 0, 0, 0, 0, 0, 0, 0, 3 ] } }, { "Return": { "id": "0000000000000000000000000000000000000000000000000000000000000000", "val": 1, "pc": 10388, "is": 10368 } }, { "ScriptResult": { "result": "Success", "gas_used": 89279 } } ] } ``` </details> --- The tracing is inspired by transaction trace provided by `cast run <tx-hash>` tool from foundry. Example usage/output of `cast run`: <img width="711" alt="image" src="https://github.com/user-attachments/assets/ad403c45-8944-4e26-95c3-a6804ef62fe3" /> --- ## Copilot Description This pull request introduces changes to the `forc-call` CLI, focusing on: - improving ABI handling - error reporting - transaction processing It refactors the `call_function` and `transfer` operations, introduces new structures for ABI management, and enhances the verbosity options for debugging transaction outputs. ### Enhancements to ABI Handling: * Introduced a new `Abi` struct to encapsulate `ProgramABI`, `UnifiedProgramABI`, and a type lookup map, simplifying ABI parsing and usage (`forc-plugins/forc-client/src/op/call/mod.rs`). * Updated `call_function` to use the new `Abi` struct and refactored ABI parsing to improve error handling during contract function calls (`forc-plugins/forc-client/src/op/call/call_function.rs`) [[1]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeL49-R62) [[2]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeL213-R245). ### Improvements in Transaction Processing: * Enhanced the `process_transaction_output` function to include `CallData` for better handling of ABI and contract-related data. Also, added support for printing transaction traces and logs with higher verbosity levels (`forc-plugins/forc-client/src/op/call/mod.rs`). * Refactored receipt handling in `call_function` to include detailed error reporting and optional ABI mappings for debugging (`forc-plugins/forc-client/src/op/call/call_function.rs`). ### Code Simplification and Refactoring: * Removed redundant `ProgramABI` usage in the `transfer` function and updated it to use the new transaction processing logic (`forc-plugins/forc-client/src/op/call/transfer.rs`). * Consolidated imports and removed unused dependencies across multiple files to streamline the codebase (`forc-plugins/forc-client/src/op/call/call_function.rs`, `forc-plugins/forc-client/src/op/call/mod.rs`, `forc-plugins/forc-client/src/op/call/transfer.rs`) [[1]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeL6-R18) [[2]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeL32-R33) [[3]](diffhunk://#diff-6b8144a652cd418525566ff9da96c87495dd239934e78788f2f79422657e5960L2-L8). ### Enhanced Debugging and Verbosity: * Added a new `print_receipts_and_trace` function to format and display transaction receipts and traces based on verbosity levels, aiding in debugging complex transactions (`forc-plugins/forc-client/src/op/call/mod.rs`). * Renamed `script` to `script_json` in `CallResponse` for clarity and consistency with JSON output conventions (`forc-plugins/forc-client/src/op/call/mod.rs`). ## 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-05-30 03:00:17 +00:00
BlockyJ	ee565f9145	feat: implement forc add and forc remove to add/remove dependencies (#7143) ... ## Description Close #2369 **Summary:** Implements functionality for `forc` to add remove dependencies through cli, similar to Cargo's `add` and `remove` commands. **Work Done:** * ✅ Added `forc add` command to support adding both regular and contract dependencies from path, git, IPFS, or version. * ✅ Implemented conflict checks for version + source collisions (e.g., version + git). * ✅ Added automatic fallback to workspace-relative path for local packages. * ✅ Introduced `forc remove` to cleanly remove specified dependencies from the manifest. * ✅ Modularized update logic using `DepSection` enum for unified regular/contract dependency handling. * ✅ Used `toml_edit` to update the manifest file while preserving formatting. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-05-21 23:47:46 -07:00
zees-dev	dffa29c599	feat: forc call json output (#7156) ... ## Description This PR adds JSON output support for `forc-call` CLI. Additionally, it adds JSON support for `tracing-subscriber` in `forc-tracing` - with option to omit logs from other libraries (via regex). - JSON tracing-subscriber ignores colored output - Forc-call hooks into this tracing-subscriber (using `Json` variant) to output JSON response ### Changelog This pull request introduces enhancements to the `forc-call` plugin, focusing on improving output formatting, streamlining verbosity handling, and updating test cases to reflect these changes. The most significant updates include the addition of a JSON output format, the removal of the `Verbosity` struct, and modifications to test cases to handle optional results. ### Output Formatting Enhancements: * Added a new `Json` variant to the `OutputFormat` enum for outputting full tracing information in JSON format. Implemented the `Write` trait for `OutputFormat` to handle different output styles. (`forc-plugins/forc-client/src/cmd/call.rs`, [forc-plugins/forc-client/src/cmd/call.rsR60-R87](diffhunk://#diff-466e2f9659cab303594eb73a846768ecdbc1a13030e5869cdac51ddde87dd313R60-R87)) * Updated the `Command` struct to include a short option (`-o`) for specifying the output format. (`forc-plugins/forc-client/src/cmd/call.rs`, [forc-plugins/forc-client/src/cmd/call.rsL319-R319](diffhunk://#diff-466e2f9659cab303594eb73a846768ecdbc1a13030e5869cdac51ddde87dd313L319-R319)) ### Verbosity Handling Simplification: * Removed the `Verbosity` struct and its associated methods. Verbosity is now directly represented as an integer (`cmd.verbosity`) for simplicity. (`forc-plugins/forc-client/src/cmd/call.rs`, [[1]](diffhunk://#diff-466e2f9659cab303594eb73a846768ecdbc1a13030e5869cdac51ddde87dd313R60-R87); `forc-plugins/forc-client/src/op/call/call_function.rs`, [[2]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeL2-R2) [[3]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeL54-L57) [[4]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeL181-R185) [[5]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeL216-R227) ### Test Case Updates: * Modified test cases to handle optional results by calling `.unwrap()` on the `result` field where applicable. This ensures compatibility with changes to how results are processed. (`forc-plugins/forc-client/src/op/call/call_function.rs`, [[1]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeL356-R387) through [[2]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeL661-R710) These changes improve the usability and maintainability of the `forc-call` plugin, making it more robust and user-friendly. Note: This is a pre-requisite to resolve https://github.com/FuelLabs/sway/issues/7019; the output script in the JSON can be directly parsed into a `tx.json` file for `forc-debug`. ## Checklist - [ ] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] 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-05-09 20:07:27 +12:00
zees-dev	66c9c1f856	sway-book: fix forc call examples (#7133) ... ## Description This pull request introduces updates to the documentation and examples for the `forc call` command, improving clarity, organization, and usability. The most significant changes include restructuring the documentation into a new file, updating the book summary to reflect this change, and enhancing the examples in the codebase for better readability. Added dedicated section for `forc-call` under testing heading. <img width="1309" alt="image" src="https://github.com/user-attachments/assets/446f6846-e294-472c-9e71-a3f1192960c5" /> ### Documentation Updates: * **New Documentation File for `forc call`**: The detailed documentation for the `forc call` command has been moved to a new file, `docs/book/src/forc/plugins/forc_client/forc_call_docs.md`. This includes comprehensive usage examples, parameter encoding details, and troubleshooting tips. * **Removal of Old Documentation**: The old `forc_call.md` file has been removed, as its content has been migrated to the new structured format. ### Book Summary Update: * **Updated `SUMMARY.md`**: The book summary has been updated to include a link to the new `forc call` documentation under the "Testing" section for better navigation. ### Code Example Enhancements: * **Improved Examples in `call.rs`**: Examples in the `forc call` command's code file (`forc-plugins/forc-client/src/cmd/call.rs`) have been reformatted for clarity. Each example now uses markdown-style code blocks and descriptive headings, making them easier to follow. ## 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: Sophie Dankel <47993817+sdankel@users.noreply.github.com> Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2025-05-02 16:27:47 +12:00
Igor Rončević	5f64b96f9c	Implement panic expression (#7073) ... ## Description This PR introduces the `panic` expression to the language, as defined in the [ABI Errors RFC](https://github.com/FuelLabs/sway-rfcs/blob/master/rfcs/0014-abi-errors.md#panic). The `panic` expression can be used without arguments, or accept an argument that implements the `std::marker::Error` trait. The `Error` trait is implemented by the compiler for the unit `()`, string slices, and `#[error_type]` enums. Using the `panic` expression without arguments gives the symetry with the `return` expression and acts in the same way as having unit as an argument. ``` panic; panic (); panic "This is some error."; panic Errors::SomeError(42); ``` Panicking without an argument or with unit as argument is discouraged to use. In the upcoming PR that finalizes the ABI errors feature, we will emit a warning if the `panic` is used without arguments or with unit as argument. `panic` expression is available in all program kinds. In predicates it currently compiles only to revert. Once `__dbg` intrinsic is implemented, we can consider compiling to it in predicates. In the upcoming PR, the `error_codes` entry in the ABI JSON will be available for all program kinds. The dead code analysis for the `panic` expression is implemented in the straightforward way, following the current approach of connecting reverts to the exit node. This will be revisted in a separate PR, together with the open TODOs in the DCA implementation of `Return`. Essentially, we want reverting/panicking to connect to program exit and implicit returns to the exit node. Additionally, the PR: - extends `forc test` CLI attributes with `--revert-codes` that prints revert codes even if tests are successful but revert. - updates outdated "Logs Inside Tests" chapter in the documentation on unit testing. - extends the snapshot testing infrastructure to support `forc test` in snapshot tests. - fixes #7072. Partially addresses #6765. ## Breaking Change `panic` is a new reserved keyword. Once the `error_type` feature becomes integrated, compiling any existing code containing a "panic" as an identifier will result in an "Identifiers cannot be a reserved keyword." error. In this PR, `panic` keyword is hidden behind the `error_type` feature flag. This prevents existing code from breaking, unless opted-in. Note that, although being behind a feature flag, `panic` cannot be used in conditional compilation, means in combination with the `#[cfg(experimental_error_type = true/false)]`. The reason is that `cfg` evaluation happens after parsing, and we can either parse `panic` as a keyword or identifier during the parsing, because we cannot distinguish ambiguous cases like `panic;` or just `panic`. This limitation means, that introducing `panic` to `std` can be done only once the `error_type` feature is fully integrated. In practice, this is not a serious limitation, because introducing `panic` in `std` would anyhow, due to effort and design decisions, happen after the feature is integrated. We will provide a migration for this breaking change that will migrate the existing "panic" identifiers to "r#panic". ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-04-30 20:07:05 +10:00
Sophie Dankel	7206479528	Add forc-publish to release binaries (#7129) ... ## Description ## 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: Joshua Batty <joshpbatty@gmail.com>	2025-04-30 00:55:36 +00:00
Daniel Frederico Lins Leite	f736fce7ac	Debug trait and its auto implementation (#7015) ... ## Description This PR implements the `__dbg(...)` intrinsic, which is very similar to Rust `dbg!(...)` macro. Up until now, it has being the norm to use `__log` to debug values. Given that this is NOT the first use case for log, we have always found some issues with it: log does not work on predicates, log does not show "private" fields like `Vec::capacity` and others. To solve these problems `__dbg` is being introduced: 1 - it will work on all program types, including predicates; 2 - it also prints the file name, line and column; 3 - All types will have an automatic implementation of Debug if possible, which can still be customized. 4 - Even `raw_ptr` and other non "loggable" types, have `Debug` impls. 5 - `__dbg` will be completely stripped in the release build by default. It can be turned on again if needed. So this: ``` // Aggregates let _ = __dbg((1u64, 2u64)); let _ = __dbg([1u64, 2u64]); // Structs and Enums let _ = __dbg(S { }); let _ = __dbg(E::None); let _ = __dbg(E::Some(S { })); ``` will generate this: ``` [src/main.sw:19:13] = (1, 2) [src/main.sw:20:13] = [1, 2] [src/main.sw:23:13] = S { } [src/main.sw:24:13] = None [src/main.sw:25:13] = E(S { }) ``` How does this work? `__dbg(value)` intrinsic is desugared into `{ let f = Formatter{}; f.print_str(...); let value = value; value.fmt(f); value }`. `Formatter` is similar to Rust's one. The difference is that we still do not support string formatting, so the `Formatter` has a lot of `print_*` functions. And each `print` function calls a "syscall". This `syscall` uses `ecal` under the hood and it follows unix write syscall schema. ```sway // ssize_t write(int fd, const void buf[.count], size_t count); fn syscall_write(fd: u64, buf: raw_ptr, count: u64) { asm(id: 1000, fd: fd, buf: buf, count: count) { ecal id fd buf count; } } ``` For that to work, the VM interpreter must have its `EcalState` setup and interpret syscall number 1000 as `write`. This PR does this for `forc test` and our `e2e test suite`. Each test in `forc test` will capture these calls and only print to the terminal when requested with the `--log` flag. ## Garbage Collector and auto generated Before, we were associating all auto-generated code with a pseudo file called "&lt;autogenerated&gt;.sw" that was never garbage collected. This generated a problem inside the LSP when the `auto_impl.rs` ran a second time because of a collision in the "shareable type" map. When we try to solve this collision, choosing to keep the old value or to insert the new, the type inside the map points to already collected types and the compiler panics. This is a known problem. The workaround for this is to break the auto-generated code into multiple files. Now they are named "main.autogenerated.sw", for example. We create one pseudo-file for each real file that needs one. When we garbage collect one file, `main.sw`, for example, we also collect its associated auto-generated file. ## Checklist - [ ] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-04-22 07:49:31 -03:00
kaya	ba3a0d5635	feat: registry source resolution and builds (#7038) ... ## Description closes #3752, #6903. Adds registry source resolutions and support for building.	2025-04-09 21:09:47 -07:00
Igor Rončević	c25c5af2da	Add #[error_type] and #[error] attributes (#7058) ... ## Description This PR adds `#[error_type]` and `#[error]` attributes to the collection of known attributes, as defined in the [ABI Errors RFC](https://github.com/FuelLabs/sway-rfcs/blob/master/rfcs/0014-abi-errors.md). Additionally, the PR updates the outdated documentation for _Attributes_ and _Keywords_. Partially addresses #6765. ## 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.	2025-04-07 09:37:04 +00:00
zees-dev	d6410e37f0	Forc call transfers (#7056) ... ## Description Implementation of direct transfer of assets to an address using `forc-call` binary. Refactor of the `forc-call` binary since it now supports 3 code paths: - calling (query or tx submission) contracts - transferring assets directly to an address (recipient and/or contract) - listing contract functions with call examples ## Usage ```sh # transfer default asset (eth) to `0x2c7Fd852EF2BaE281e90ccaDf18510701989469f7fc4b042F779b58a39919Eec` forc-call 0x2c7Fd852EF2BaE281e90ccaDf18510701989469f7fc4b042F779b58a39919Eec --amount 2 --mode=live ``` ### Output ```log warning: No signing key or wallet flag provided. Using default signer: 0x6b63804cfbf9856e68e5b6e7aef238dc8311ec55bec04df774003a2c96e0418e Transferring 2 0xf8f8b6283d7fa5b672b530cbb84fcccb4ff8dc40f8176ef4544ddb1f1952ad07 to recipient address 0x2c7fd852ef2bae281e90ccadf18510701989469f7fc4b042f779b58a39919eec... tx hash: e4e931276a500cce1b5303cb594c0477968124ab0f70e77995bbb4499e0c3350 ``` ## Additional notes - Inspired by `cast send` where if the CLI is called without a function signature, it transfers value (eth) to the target address based on the `--value` parameter; `forc-call` does the same via the `--amount` param - One can specify the `asset` to be sent; defaults to native network asset (`eth`) - Transfers only work with `--mode=live`; since there is no simulation/dry-run functionality available for this - Transfers to both contracts and user recipients is supported ## Checklist - [ ] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: z <zees-dev@users.noreply.github.com> Co-authored-by: kaya <kaya.gokalp@fuel.sh> Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2025-04-06 23:38:47 -07:00
Igor Rončević	74282e2c7b	Defining, parsing, and checking #[attribute]s (#6986) ... ## Description This PR reimplements how `#[attribute]`s are parsed, defined, and checked. It fixes the following issues we had with attributes: - attributes were in general not checked for their expected and allowed usage. - when checked, checks were fixing particular reported issues and were scattered through various compilation phases: lexing, parsing, and tree conversion. - when checked, reported errors in some cases had bugs and were overalapping with other errors and warnings. - attribute handling was not centralized, but rahter scattered throught the whole code base, and mostly done at use sites. For concrete examples of these issues, see the list of closed issues below. The PR: - encapsulates the attributes handling within a single abstraction: `Attributes`. - assigns the following properties to every attribute: - _target_: what kind of elements an attribute can annotate. - _multiplicity_: if more then one attribute of the same kind can be applied to an element. - _arguments multiplicity_: a range defining how many arguments an attribute can or must have. - _arguments value expectation_: if attribute arguments are expected to have values. - validates those properties in a single place, during the `convert_parse_tree`. Note that this means that modules with attribute issues will now consistently not reach the type checking phase. This was previously the case for some of the issues with attributes where custom checks where done during the type checking phase. #6987 proposes to move those checks after the tree conversion phase, allowing the continuation of compilation. - adds the `AttributeKind::Unknow` to preserve unknown attributes in the typed tree. - removes redundant code related to attributes: specific warnings and errors, specialized parsing, repetitive and error-prone at use site checks, etc. - removes the unused `Doc` attribute. The PR also introduces a new pattern in emitting errors. The `attr_decls_to_attributes` function will always return `Attributes` even if they have errors, because: - we expect the compilation to continue even in the case of errors. - we expect those errors to be ignored if a valid `#[cfg]` attribute among those evaluates to false. - we expect them to be emitted with eventual other errors, or alone, at the end of the tree conversion of the annotated element. For more details, see the comment on `attr_decls_to_attributes` and `cfg_eval`. Closes #6880; closes #6913; closes #6914; closes #6915; closes #6916; closes #6917; closes #6918; closes #6931; closes #6981; closes #6983; closes #6984; closes #6985. ## Breaking changes Strictly seen, this PR can cause breaking changes, but only in the case of invalid existing attribute usage. We treat those breaking changes as bug fixes in the compiler and, thus, do not have them behind a feature flag. E.g., this kind of code was possible before, but will now emit and error: ```sway #[storage(read, write, read, write)] struct Struct {} ``` ## 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.	2025-03-24 09:34:31 +11:00
zees-dev	6cd732b56e	forc-call list functions support with example call usage (#7018) ... ## Description Adds optional `--list-functions` CLI arg to `forc call`. With provided ABI and a contract address; calling `forc-call` with `--list-functions` will list all available functions in the contract and additionally display example CLI usage to call the respective functions with default/basic parameters. ## Example output ```sh > forc call -- \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 --list-functions Available functions in contract: 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 test_array(a: [u64; 10]) -> [u64; 10] forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_array "[0, 0, 0, 0, 0, 0, 0, 0, 0, 0]" test_b256(a: b256) -> b256 forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_b256 "0x0000000000000000000000000000000000000000000000000000000000000000" test_bytes(a: Bytes) -> Bytes forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_bytes "0x" test_complex_struct(a: ComplexStruct) -> ComplexStruct forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_complex_struct "{({aa, 0}, 0), (Active:false), 0, {{0, aaaa}, aaaa}}" test_empty() -> () forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_empty test_empty_no_return() -> () forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_empty_no_return test_enum(a: Status) -> Status forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_enum "(Active:false)" test_enum_with_complex_generic(a: GenericEnum) -> GenericEnum forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_enum_with_complex_generic "(container:{{0, aaaa}, aaaa})" test_enum_with_generic(a: GenericEnum) -> GenericEnum forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_enum_with_generic "(container:{0, aaaa})" test_option(a: Option) -> Option forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_option "(None:())" test_str(a: str) -> str forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_str "hello" test_str_array(a: str[10]) -> str[10] forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_str_array "aaaaaaaaaa" test_str_slice(a: str) -> str forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_str_slice "hello" test_struct(a: User) -> User forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_struct "{aa, 0}" test_struct_with_generic(a: GenericStruct) -> GenericStruct forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_struct_with_generic "{0, aaaa}" test_tuple(a: (u64, bool)) -> (u64, bool) forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_tuple "(0, false)" test_u128(a: U128) -> U128 forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_u128 "0" test_u16(a: u16) -> u16 forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_u16 "0" test_u256(a: U256) -> U256 forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_u256 "0" test_u32(a: u32) -> u32 forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_u32 "0" test_u64(a: u64) -> u64 forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_u64 "0" test_u8(a: u8) -> u8 forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_u8 "0" test_unit(a: ()) -> () forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_unit "()" test_vector(a: Vec<u64>) -> Vec<u64> forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_vector "[0, 0]" transfer(amount_to_transfer: u64, asset_id: AssetId, recipient: Identity) -> () forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ transfer "0" "{0x0000000000000000000000000000000000000000000000000000000000000000}" "(Address:{0x0000000000000000000000000000000000000000000000000000000000000000})" ``` Addresses https://github.com/FuelLabs/sway/issues/6935 ## 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. - [ ] 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-03-18 15:09:10 +13:00
SwayStar123	a5d9d2835f	Merge std and core libraries (#6729) ... ## Description Merges the two libraries. They were initially separate to separate the core logic and fuel vm specific functionality, but that separation is no longer maintained so having a merged library is better. Closes #6708 ## Checklist - [ ] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: Sophie <47993817+sdankel@users.noreply.github.com> Co-authored-by: Igor Rončević <ironcev@hotmail.com>	2025-03-12 23:52:38 +01:00
Sophie Dankel	d00c0fe44d	feat: Support categories and keywords in forc manifest (#6974) ... ## Description Related https://github.com/FuelLabs/forc.pub/issues/30 ## 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-03-03 14:17:45 -08:00
zees-dev	20973803db	forc-call logs support (#6968) ... ## Description - Added support for viewing emitted logs when making a transaction using forc-call - Added `show_receipts` param (default-false) - so we can optionally prnt out all receipts - The CLI output becomes too long for a call with multiple receipts; this is a minor UI enhancement Addresses https://github.com/FuelLabs/sway/issues/6887 ## Example usage/output ```sway script; struct ExampleParams { test_val: u32, test_str: str, test_tuple: (u32, u64), } fn main() -> u64 { log("hiiii"); log(123); log(ExampleParams { test_val: 5, test_str: "hello world", test_tuple: (1,2) }); 5 } ``` <img width="986" alt="image" src="https://github.com/user-attachments/assets/3725ff17-29c9-43d7-98cc-4cacfc213ecb" /> ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: z <zees-dev@users.noreply.github.com> Co-authored-by: Joshua Batty <joshpbatty@gmail.com> Co-authored-by: kayagokalp <kayagokalp123@gmail.com>	2025-03-01 14:26:16 +13:00
Kaya Gökalp	15899514eb	feat: add forc-node command for easily bootstrapping a node (#6473)	2025-02-15 12:34:45 +11:00
zees-dev	696cb57883	minor: Migrate forc-call node_url (#6920) ... ## Description Migrated the `node_url` function; addressing the todo. Also refactored the function to ease readability and maintainability. ## 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). - [ ] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: z <zees-dev@users.noreply.github.com>	2025-02-14 15:01:28 +13:00
Igor Rončević	1270bfa53f	Marker traits (#6871) ... ## Description This PR introduces the concept of marker traits to the language. It is the first step towards implementing the [ABI errors RFC](https://github.com/FuelLabs/sway-rfcs/blob/master/rfcs/0014-abi-errors.md). Marker traits are traits automatically generated by the compiler. They represent certain properties of types and cannot be explicitly implemented by developers. The PR implements a common infrastructure for generating and type-checking marker traits as well as two concrete marker traits: - `Error`: represents a type whose instances can be used as arguments for the `panic` expression. (The `panic` expression is yet to be implemented.) - `Enum`: represents an enum type. Combining these two marker traits in trait constraints allow expressing constraints such is, e.g., "the error type must be an error enum": ``` fn panic_with_error<E>(err: E) where E: Error + Enum { panic err; } ``` Note that the generic name `Enum` is sometimes used in our tests to represent a dummy enum. In tests, it is almost always defined locally, and sometimes explicitly imported, so it will never clash with the `Enum` marker trait. A single test in which the clash occurred was easily adapted by explicitly importing the dummy `Enum`. The PR is the first step in implementing #6765. ## 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.	2025-02-07 03:25:57 +00:00
zees-dev	0de1c32c22	plugin: forc-call (#6791) ... ## Description The following PR introduces a new forc plugin; `forc-call`. This plugin allows users to call functions on deployed contracts using the `forc call` command. This is ideal for quickly querying the state of a deployed contract. In this first implementation; the contract ABI is required (as a path to a local JSON file or a URL to a remote JSON file). This is inspired by the [`cast call`](https://book.getfoundry.sh/reference/cast/cast-call) tool; which is a popular tool for interacting with deployed contracts on Ethereum. The implementation is based on the following Github issue: https://github.com/FuelLabs/sway/issues/6725 In the current implementation, you can query a contract state using the `forc call` command by providing the target contract ID, it's respective ABI file, and the function name (selector) and arguments. <details> <summary>Forc Call CLI</summary> ```sh forc call --help ``` ``` Call a contract function Usage: forc call [OPTIONS] <CONTRACT_ID> <FUNCTION> [ARGS]... Arguments: <CONTRACT_ID> The contract ID to call <FUNCTION> The function signature to call. When ABI is provided, this should be a selector (e.g. "transfer") When no ABI is provided, this should be the full function signature (e.g. "transfer(address,u64)") [ARGS]... Arguments to pass into main function with forc run Options: --abi <ABI> Optional path or URI to a JSON ABI file --node-url <NODE_URL> The URL of the Fuel node to which we're submitting the transaction. If unspecified, checks the manifest's `network` table, then falls back to `http://127.0.0.1:4000` You can also use `--target`, `--testnet`, or `--mainnet` to specify the Fuel node. [env: FUEL_NODE_URL=] --target <TARGET> Use preset configurations for deploying to a specific target. You can also use `--node-url`, `--testnet`, or `--mainnet` to specify the Fuel node. Possible values are: [local, testnet, mainnet] --testnet Use preset configuration for testnet. You can also use `--node-url`, `--target`, or `--mainnet` to specify the Fuel node. --mainnet Use preset configuration for mainnet. You can also use `--node-url`, `--target`, or `--testnet` to specify the Fuel node. --signing-key <SIGNING_KEY> Derive an account from a secret key to make the call [env: SIGNING_KEY=] --wallet Use forc-wallet to make the call --amount <AMOUNT> Amount of native assets to forward with the call [default: 0] --asset-id <ASSET_ID> Asset ID to forward with the call --gas-forwarded <GAS_FORWARDED> Amount of gas to forward with the call --mode <MODE> The execution mode to use for the call; defaults to dry-run; possible values: dry-run, simulate, live [default: dry-run] --gas-price <PRICE> Gas price for the transaction --script-gas-limit <SCRIPT_GAS_LIMIT> Gas limit for the transaction --max-fee <MAX_FEE> Max fee for the transaction --tip <TIP> The tip for the transaction --external-contracts <EXTERNAL_CONTRACTS> The external contract addresses to use for the call If none are provided, the call will automatically extract contract addresses from the function arguments and use them for the call as external contracts -h, --help Print help (see a summary with '-h') -V, --version Print version ``` </details> ### Example usage ```sh forc call 0xe18de7c7c8c61a1c706dccb3533caa00ba5c11b5230da4428582abf1b6831b4d --abi ./out/debug/counter-contract-abi.json add 1 2 ``` - where `0xe18de7c7c8c61a1c706dccb3533caa00ba5c11b5230da4428582abf1b6831b4d` is the contract ID - where `./out/debug/counter-contract-abi.json` is the path to the ABI file - where `add` is the function name (selector) - where `1 2` are the arguments to the function ^ the sway code for the add function could be: ```sway contract; abi MyContract { fn add(a: u64, b: u64) -> u64; } impl MyContract for Contract { fn add(a: u64, b: u64) -> u64 { a + b } } ``` ## Implementation details 1. The provided ABI file downloaded (unless local path is provided) 2. The ABI is parsed into internal representation 3. The provided function selector e.g. `add` is matched with the extracted functions from the ABI 4. The provided arguments are parsed into the appropriate types which match the extracted function's inputs 5. The function selector and args are then converted into the `Token` enum, which is then ABI encoded as part of the `ContractCall` struct 6. The `ContractCall` struct is then used to make a request to the node to call the function 7. The response is then decoded into the appropriate type (based on matched function's output type) ^ In the implementation, we don't use the `abigen!` macro since this is a compile time parser of the ABI file; instead we make use of the lower level encoding and decoding primitives and functions from the [Rust SDK](https://github.com/FuelLabs/fuels-rs). ## Live example on testnet ### Example 1 The example contract above with `add` function has been deployed on testnet - with ABI file available [here](https://pastebin.com/raw/XY3awY3T). The add function can be called via the CLI: ```sh cargo run -p forc-client --bin call -- \ --testnet \ --abi https://pastebin.com/raw/XY3awY3T \ 0xe18de7c7c8c61a1c706dccb3533caa00ba5c11b5230da4428582abf1b6831b4d \ add 1 2 ``` ### Example 2 - get `owner` of Mira DEX contract ```sh cargo run -p forc-client --bin call -- \ --testnet \ --abi https://raw.githubusercontent.com/mira-amm/mira-v1-periphery/refs/heads/main/fixtures/mira-amm/mira_amm_contract-abi.json \ 0xd5a716d967a9137222219657d7877bd8c79c64e1edb5de9f2901c98ebe74da80 \ owner ``` Note: Testnet contract address [here](https://docs.mira.ly/developer-guides/developer-overview#testnet-deployment) ## Encoding of primitive types When passing in function arguments, the following types are encoded as follows: | Types | Example input | Notes | |-----------------------------------------------|----------------------------------------------------------------------|------------------------------------------------------------------------------------------------| | bool | `true` or `false` | | | u8, u16, u32, u64, u128, u256 | `42` | | | b256 | `0x0000000000000000000000000000000000000000000000000000000000000042` or `0000000000000000000000000000000000000000000000000000000000000042` | `0x` prefix is optional | | bytes, RawSlice | `0x42` or `42` | `0x` prefix is optional | | String, StringSlice, StringArray (Fixed-size) | `"abc"` | | | Tuple | `(42, true)` | The types in tuple can be different | | Array (Fixed-size), Vector (Dynamic) | `[42, 128]` | The types in array or vector must be the same; i.e. you cannot have `[42, true]` | | Struct | `{42, 128}` | Since structs are packed encoded, the attribute names are not encoded; i.e. `{42, 128}`; this could represent the following `struct Polygon { x: u64, y: u64 }` | | Enum | `(Active: true)` or `(1: true)` | Enums are key-val pairs with keys as being variant name (case-sensitive) or variant index (starting from 0) and values as being the variant value; this could represent the following `enum MyEnum { Inactive, Active(bool) }` | <details> <summary>Encoding cheat-sheet</summary> A few of the common types are encoded as follows: | Types | Encoding Description | Example | |--------------------------------------------|--------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------| | bool, u8 | Encoded as a single byte. `bool`: 0x00 (false) or 0x01 (true); `u8` is the byte itself. | `bool(true) = 0x01`, `u8(42) = 0x2A` | | u16 | 2-byte, big-endian | `u16(42) = 0x002A` | | u32 | 4-byte, big-endian | `u32(42) = 0x0000002A` | | u64 | 8-byte, big-endian | `u64(42) = 0x000000000000002A` | | u128 | 16-byte, big-endian | `u128(42) = 0x0000000000000000000000000000002A` | | u256, b256 | 32-byte value. For u256: big-endian integer; For b256: raw 32 bytes | `u256(42) = 32-bytes ending with ...0000002A`, `b256(...) = exactly the 32-byte array` | | Tuples, Arrays, Structs (Fixed-size) | Concatenate the encodings of each element/field with no extra padding | `(u8(1), bool(true)) = 0x01 0x01`; `[u16;2]: [42,100] = 0x002A0064`; `struct {u8,u8}: 0x0102` | | Enums | `u64` variant index + encoded variant data with no extra padding | `MySumType::X(42): 0x0000000000000000 000000000000002A` | | Bytes, String, RawSlice, Vector (Dynamic) | `u64` length prefix + raw data, no padding | `"abc" = length=3: 0x0000000000000003 0x61 0x62 0x63` | ^ This is based on the docs here: https://docs.fuel.network/docs/specs/abi/argument-encoding </details> ## Future improvements 1. Support for function signature based calls without ABI 2. Support for raw calldata input 3. Function selector completion - given ABI file ## 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: zees-dev <zees-dev@users.noreply.github.com> Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com> Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2025-02-07 02:30:52 +00:00
Joshua Batty	0a56930e05	forc-debug: Add ABI support for decoding log values (#6856) ... ## Description Adds support for ABI files in `forc-debug` to decode log values while debugging using the CLI. Users can now: for example: ``` tx tx.json abi.json ``` When the Sway ABI Registry is available, the debugger will automatically fetch ABIs for deployed contracts. Have an issue open to implement this here #6862 Updates documentation to show decoded log output, adds tab completion for ABI files, and refreshes bytecode examples to match current output. The `test_cli` test has been updated to take an ABI and check that the correct decoded value is returned. ## 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.	2025-02-04 06:16:29 +01:00
Sophie Dankel	176271445c	feat: Add support for additional package manifest keys (#6868) ... ## Description Adds new keys to the package manifest's project section. These will be used when publishing packages. ## 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-01-30 09:55:10 +11:00
Cameron Carstens	b03c76e482	Introduce crypto module and expand cryptographic functions (#6837) ... ## Description This PR replaces https://github.com/FuelLabs/sway/pull/5747 and intends to introduce the crypto module. > Note: https://github.com/FuelLabs/sway/pull/6832 will also use the crypto module. The std-lib currently contains the `ecr.sw` and `vm/evm/ecr.sw` files which have the following functions: - ec_recover() - ec_recover_r1() - ed_verify() - ec_recover_address() - ec_recover_address_r1() - ec_recover_evm_address() There are a number of issues with this including no type safety for signatures from different elliptic curves, functions split across multiple files, poor naming, and generic arguments. All of these are resolved by this PR which deprecates both `ecr.sw` files and replaces them with a crypto module which syntactically matches Rust. The following new types are introduced: * `PublicKey` - An Asymmetric public key, supporting both 64 and 32-byte public keys * `Message` - Hashed message authenticated by a signature type that handles variable lengths * `Secp256k1` - A secp256k1 signature * `Secp256r1` - A secp256r1 signature * `Ed25519` - An ed25519 signature * `Signature` - An ECDSA signature All original functionality is retained with the new module: * `Secp256k1::recover()` - Recovers a public key. * `Secp256r1::recover()` - Recovers a public key. * `Secp256k1::address()` - Recovers an address. * `Secp256r1::address()` - Recovers an address. * `Secp256k1::evm_address()` - Recovers an EVM address. * `Ed25519::verify()` - Verify that a signature matches the given public key. The following new functionality has been added: * `Secp256k1::verify()` - Verify that a signature matches the given public key. * `Secp256r1::verify()` - Verify that a signature matches the given public key. * `Secp256k1::verify_address()` - Verify that a signature matches the given address. * `Secp256r1::verify_address()` - Verify that a signature matches the given address. * `Secp256k1::verify_evm_address()` - Verify that a signature matches the given EVM address. * `Secp256r1::verify_evm_address()` - Verify that a signature matches the given EVM address. * `Secp256r1::evm_address()` - Recovers an EVM address. The following functions have been deprecated: - `std::ecr::ec_recover()` - `std::ecr::ec_recover_r1()` - `std::ecr::ed_verify()` - `std::ecr::ec_recover_address()` - `std::ecr::ec_recover_address_r1()` - `std::vm::evm::ecr::ec_recover_evm_address()` Example of changes for recovering a public key: ```sway // Before fn foo(signature: B512, message: b256) { let recovered_public_key: B512 = ec_recover(signature, message).unwrap(); } // After fn bar(signature: Signature, message: Message) { let recovered_public_key: PublicKey = signature.recover(message).unwrap(); } ``` Example of changes for recovering an Address: ```sway // Before fn foo(signature: B512, message: b256) { let recovered_address: Address = ec_recover_address(signature, message).unwrap(); } // After fn bar(signature: Signature, message: Message) { let recovered_address: Address = signature.address(message).unwrap(); } ``` Complete recovery example using the `Signature` type: ```sway use std::crypto::{Message, PublicKey, Secp256r1, Signature}; fn foo() { let secp256r1_signature = Signature::Secp256r1(Secp256r1::from(( 0xbd0c9b8792876712afadbff382e1bf31c44437823ed761cc3600d0016de511ac, 0x44ac566bd156b4fc71a4a4cb2655d3da360c695edb27dc3b64d621e122fea23d, ))); let signed_message = Message::from(0x1e45523606c96c98ba970ff7cf9511fab8b25e1bcd52ced30b81df1e4a9c4323); // A recovered public key pair. let secp256r1_public_key = secp256r1_signature.recover(signed_message); assert(secp256r1_public_key.is_ok()); assert( secp256r1_public_key .unwrap() == PublicKey::from(( 0xd6ea577a54ae42411fbc78d686d4abba2150ca83540528e4b868002e346004b2, 0x62660ecce5979493fe5684526e8e00875b948e507a89a47096bc84064a175452, )), ); } ``` ## 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.	2025-01-25 23:23:40 +01:00
Igor Rončević	7aa59f987c	Add forc-migrate tool (#6790) ... ## Description This PR introduces `forc-migrate`, a Forc tool for migrating Sway projects to the next breaking change version of Sway. The tool addresses two points crucial for code updates caused by breaking changes: - it informs developers about the breaking changes and **assists in planing and executing** the migration. - it **automatically changes source code** where possible, reducing the manual effort needed for code changes. Besides adding the `forc-migrate` tool, the PR: - extends `Diagnostic` to support migration diagnostics aside with errors and warnings. - changes `swayfmt` to support generating source code from arbitrary lexed trees. The change is a minimal one done only in the parts of `swayfmt` that are executed by migration steps written in this PR. Adapting `swayfmt` to fully support arbitrary lexed trees will be done in #6779. The migration for the `references` feature, migrating `ref mut` to `&mut`, is developed only partially, to demonstrate the development and usage of automatic migrations that alter the original source code. The intended usage of the tool is documented in detail in the "forc migrate" chapter of The Sway Book: _Forc reference > Plugins > forc_migrate_. (The generated documentation has issues that are caused by the documentation generation bug explained in #6792. These issues will be fixed in a separate PR that will fix it for all the plugins.) We expect the `forc-migrate` to evolve based on the developer's feedback. Some of the possible extensions of the tool are: - adding additional CLI options, e.g., for executing only specific migration steps, or ignoring them. - passing parameters to migration steps from the CLI. - not allowing updates by default, if the repository contains modified or untracked files. - migrating workspaces. - migrating other artifacts, e.g., Forc.toml files or contract IDs. - migrating between arbitrary versions of Sway. - migrating SDK code. - etc. `forc-migrate` also showed a clear need for better infrastructure for writing static analyzers and transforming Sway code. The approach used in the implementation of this PR should be seen as a pragmatic beginning, based on the reuse of what we currently have. Some future options are discussed in #6836. ## Demo ### `forc migrate show` Shows the breaking change features and related migration steps. This command can be run anywhere and does not require a Sway project. ``` Breaking change features: - storage_domains (https://github.com/FuelLabs/sway/issues/6701) - references (https://github.com/FuelLabs/sway/issues/5063) Migration steps (1 manual and 1 semiautomatic): storage_domains [M] Review explicitly defined slot keys in storage declarations (`in` keywords) references [S] Replace `ref mut` function parameters with `&mut` Experimental feature flags: - for Forc.toml: experimental = { storage_domains = true, references = true } - for CLI: --experimental storage_domains,references ``` ### `forc migrate check` Performs a dry-run of the migration on a concrete Sway project. It outputs all the occurrences in code that need to be reviewed or changed, as well as the migration time effort: ``` info: [storage_domains] Review explicitly defined slot keys in storage declarations (`in` keywords) --> /home/kebradalaonda/Desktop/M Forc migrate tool/src/main.sw:19:10 | ... 19 | y in b256::zero(): u64 = 0, | ------------ 20 | z: u64 = 0, 21 | a in calculate_slot_address(): u64 = 0, | ------------------------ 22 | b in 0x0102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f20: u64 = 0, | ------------------------------------------------------------------ | = help: If the slot keys used in `in` keywords represent keys generated for `storage` fields = help: by the Sway compiler, those keys might need to be recalculated. = help: = help: The previous formula for calculating storage field keys was: `sha256("storage.<field name>")`. = help: The new formula is: `sha256((0u8, "storage.<field name>"))`. = help: = help: For a detailed migration guide see: https://github.com/FuelLabs/sway/issues/6701 ____ Migration effort: storage_domains [M] Review explicitly defined slot keys in storage declarations (`in` keywords) Occurrences: 3 Migration effort (hh::mm): ~00:06 references [S] Replace `ref mut` function parameters with `&mut` Occurrences: 0 Migration effort (hh::mm): ~00:00 Total migration effort (hh::mm): ~00:06 ``` ### `forc migrate run` Runs the migration steps and guides developers through the migration process. ## 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.	2025-01-20 13:14:20 +01:00
Igor Rončević	4fe687094e	Implement Iterator for StorageVec (#6821) ... ## Description This PR implements `Iterator` for `StorageVec`. Iterating over a `StorageVec` via `for` loop should now be the preferred option. Compared to the traversal via `while` loop and incrementing index, the `for` loop is: - more performant. `for` loop eliminates the redundant boundary checks done in every `get()` call in the `while` loop. - more idiomatic and convenient. Closes #6796. ## 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: bitzoic <bitzoic.eth@gmail.com>	2025-01-14 16:18:16 +01:00
Matt	cf7b6664b5	docs: add sway memory model (#6775) ... ## Description Developers get confused by Sway's memory model as it is different from Rust's. So I added this to the docs. closes https://app.asana.com/0/1207924201336629/1208429018056446 ## Checklist - [x] I have linked to any relevant issues. - [ ] 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) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - x ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>	2024-12-20 10:47:39 -06:00
zees-dev	519f208a05	Forc.toml metadata support (#6728) ... # Description Adds support for `metadata` as `[project.metadata]` or `[workspace.metadata]` in `Forc.toml` of value `toml::Value` - Addresses: 22bf3936a3/text/rfcs/0006-metadata-in-forc-manifest.md (reference-level-explanation) - Resolves: https://github.com/FuelLabs/sway/issues/2180 ## Linked examples of usage - https://github.com/FuelLabs/example-forc-plugins/pull/1 --------- Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>	2024-11-19 16:48:32 +13:00
Kaya Gökalp	8073fab0b6	docs: remove dead links to sway-libs/fixed-point (#6689) ... ## Description closes #6636. closes #6631. As of https://github.com/FuelLabs/sway-libs/pull/278 sway-libs/fixed-point library is deprecated and removed completely from sway-libs repo. We should not link it from our book as well.	2024-11-03 23:39:54 -08:00
0x77	7e499fe24d	[docs] Update ::call_frames::ContractId to ::contract_id::ContractId in Native Assets Documentation (#6141) ... ## Description The syntax `std::call_frames::ContractId` has been updated in the latest version of Sway. The new syntax is `std::contract_id::ContractId`. To ensure the documentation is accurate and consistent with the latest version, this update is necessary. ## Reason for Change: - The `std::call_frames::ContractId` syntax has been deprecated or modified in the latest version of Sway. - Using the latest `std::contract_id::ContractId` syntax ensures the documentation is accurate and helps developers avoid using outdated syntax. ## Reference #5867 ## 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). - [ ] I have requested a review from the relevant team or maintainers. Co-authored-by: IGI-111 <igi-111@protonmail.com>	2024-10-28 14:48:26 +01:00
mcisb	cbfd9621d0	style: update troubleshooting.md (#6632) ... Co-authored-by: K1-R1 <77465250+K1-R1@users.noreply.github.com> Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2024-10-16 10:02:56 +11:00