274 commits

Author	SHA1	Message	Date
Igor Rončević	1da5e662e8	Compile runtime backtracing to ASM and compile-time to ABI JSON (#7387) ... ## Description This PR implements the compilation of the ABI backtracking, as described in the [ABI Backtracking RFC](https://github.com/FuelLabs/sway-rfcs/blob/ironcev/abi-backtracing/rfcs/0016-abi-backtracing.md). The PR closes two remaining implementation steps listed in the #7276: - Compile runtime backtracing to ASM and compile-time to ABI JSON - Support backtracing in forc test ### Changes in the ABI JSON and IR Compilation #### `panickingCalls` section in the ABI JSON Each panicking call is identified by a unique number and provided in the new `panickingCalls` section in the ABI JSON. E.g., for this panicking call in a module `some_module` of a package `some_package`: ```sway fn some_function() { let _ = this_function_might_panic(42); } ``` the following ABI JSON entry is created: ```json "panickingCalls": { "1": { "pos": { "function": "some_package::some_module::some_function", "pkg": "some_package@0.1.0", "file": "src/some_module.sw", "line": 4, "column": 8 }, "function": "some_other_package::module::this_function_might_panic" }, } ``` #### Encoding error code and backtrace in a `panic` revert code The generation of the `panic` revert code is changed. A `panic` revert code now encodes: - the information that the revert is generated by a `panic` expression, - the actual error code that can be located in the `errorCodes` section of the ABI JSON, - up to five panicking call IDs, encoded in the order of calling, that can be located in the `panickingCalls` section of the ABI JSON. The encoding of the `u64` revert code works as following: ```console 1_pppppppp_CCCCCCCCCCC_CCCCCCCCCCC_CCCCCCCCCCC_CCCCCCCCCCC_CCCCCCCCCCC ``` - The leading `1` denotes a revert code generated by a `panic` expression. Arbitrary user-defined revert codes will must have the starting bit set to `0` or in other words be less then or equal to `9223372036854775807₁₀ = 7FFFFFFFFFFFFFFF₁₆`. - The `pppppppp` denotes the error code in the `errorCodes` section of the ABI JSON, that identifies the actual `panic` location. - Each `CCCCCCCCCCC` section denotes a panicking call code in the `panickingCalls` section of the ABI JSON. The calls represent the callstack, where the right-most code is the code of the immediate function call in which the `panic` occurs. If all `C`s a zero it means no-call. This will happen if the actual call-depth is less then five calls. #### Calculating backtrace Ever non-entry function that can panic gets an additional function argument: `__backtrace: u64`. The `__backtrace` to pass to a panicking call is calculated at runtime by left-shift the existing `__backtrace` provided by the caller function and append/bitwise OR the unique panicking call ID of the exact panicking call. The ID of that exact panicking call is a compile-time, compiler-generated constant as explained above. The detailed mechanism with examples is provided in the "Runtime execution and bytecode and gas overhead" chapter of the [ABI Backtracking RFC](https://github.com/FuelLabs/sway-rfcs/blob/ironcev/abi-backtracing/rfcs/0016-abi-backtracing.md). ## Additional Changes The `panickingCalls` section of the ABI JSON can differ between `debug` and `release` builds which required adding support for different ABI JSON oracle files in test that `validate_abi`. The requirement to display a fully qualified function name in the panicking call and the backtrace resulted in adding flexibility to displaying functions and types in general. Adjusting affected tests was used as opportunity to remove unnecessary dependencies to the `std` and reduced `std` libraries in a large number of tests. Also, a cleanup is done in some parts of the code, like, e.g., removing code duplications. The PR implements these additional changes: - Implements `TyFunctionDisplay` and `TypeInfoDisplay` for configurable displaying of functions and types. Replacing current various custom implementations of displaying with these two types, mostly in error messages, will be done in separate PRs, with low priority. Also, display might be improved in some edge cases. There are TODOs left in code for such, and improvements will be done in separate PRs, with lower priority. - Displays full type names in warnings and errors, where expected. The PR intentionally temporarily switches to full type names in all errors and warnings by making that a default behavior in `impl DisplayWithEngines for TypeInfo`. This is done so that we can easily spot errors and warnings that should use specific `TyFunctionDisplay` and `TypeInfoDisplay` (tests will break) and adapt those in the follow up PR that will address #7389. That follow up PR will also address usages of type names in LSP. - Implements expressive diagnostics for `CompileError::MethodNotFound` and utilize `TyFunctionDisplay` for displaying all matching candidates. - Implements `Value::new_u64_constant` and removing duplicated code for a common scenario of creating an IR Constant of type `u64`. - Removes several unnecessary `clone()`s and `String` allocations. - Renames fields postfixed with `typeid` to follow more general naming convention for `TypeId` fields and parameters. - Removes unnecessary dependencies to `std` or reduced `std` libraries in tests. - Adds support for different `json_abi_oracle` files for `debug` and `release` build profiles. The `panickingCalls` part of the ABI JSON can vary depending on the build profile. A test that verifies ABI JSON now *must provide* expected oracles for both build profiles, unless a profile is unsupported via `unsupported_profiles` test option. An alternative was considered, to allow just a single oracle file if both `debug` and `release` oracles are the same. The reasoning for having two as mandatory even in that case was to gain more explicit test setup. We can change this upon feedback if needed. The oracles have a suffix of either `.debug.json` or `.release.json` and the name part is, as before, one of the following: - `json_abi_oracle` for obsolete old encoding, - `json_abi_oracle.<experimental feature>` for experimental features, - `json_abi_oracle_new_encoding` for new encoding without other experimental features. - Fixes #7386. - Fixes #7388. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-10-09 08:45:51 +00:00
kaya	14bb898f3b	chore: bumpt rust version to 1.90 (#7427) ... ## Description Bumping the rust version to 1.90 and fixing the clippy lints along the way	2025-10-02 22:28:51 +13:00
Joshua Batty	dfb821407a	Fix SourceEngine cache to refresh buffers after file edits (#7399) ... ## Description - Update `SourceEngine::get_or_create_source_buffer` to replace the cached buffer when the caller supplies different text. - Fixes an LSP bug where diagnostics/token spans stayed stuck on the initial buffer, causing erroneous results after text edits. ## Checklist - [ ] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-09-22 14:42:56 +01:00
Igor Rončević	84e575ab52	Optimize storage access compilation (#7357) ... ## Description This PR rewrites the compilation of storage accesses via `storage` keyword, e.g. `storage.field`. The new compilation is optimized for gas usage and bytecode size. Some performance comparisons are shown below. When accessing storage, the old compilation was repeatedly constructing the same `StorageKey` as a local variable at each storage access site. E.g., for this example: ```sway storage { scalar: u64 = 0, } impl Contract { #[storage(read)] fn poke_storage() { poke(storage.scalar); } } ``` the resulting IR was: ``` pub entry fn poke_storage() -> (), !4 { local { b256, u64, b256 } __anon_0 local b256 __const = const b256 0x9e0e87bef2e44d9771eb12cfc81e34e4dd6caad55385354757a8898a2c808b61 local b256 __const0 = const b256 0x9e0e87bef2e44d9771eb12cfc81e34e4dd6caad55385354757a8898a2c808b61 local { b256, u64, b256 } __tmp_arg entry(): // BEGIN OF `storage.scalar` ACCESS v0 = get_local ptr b256, __const v1 = get_local ptr b256, __const0 v6 = get_local ptr { b256, u64, b256 }, __anon_0, !5 v7 = const u64 0 v8 = get_elem_ptr v6, ptr b256, v7 mem_copy_val v8, v0 v9 = const u64 1 v10 = get_elem_ptr v6, ptr u64, v9 v11 = const u64 0 store v11 to v10, !5 v12 = const u64 2 v13 = get_elem_ptr v6, ptr b256, v12 mem_copy_val v13, v1 // END OF `storage.scalar` ACCESS v14 = get_local ptr { b256, u64, b256 }, __tmp_arg mem_copy_val v14, v6 v15 = call poke_2(v14) v9 = const unit () ret () v9 ``` The overall cost of each access was: - a local on the stack for each access, `__anon_0` in this case. - two `mem_copy_val`s of the storage slot and field id into that local. - storing the slot offset into that local. The bytecode size cost per access site was significant, but constant, six ASM instructions: ``` load $r0 data_NonConfigurable_0 ; get local constant load $r1 data_NonConfigurable_0 ; get local constant mcpi $$locbase $r0 i32 ; copy memory sw $$locbase $zero i4 ; store word addi $r0 $$locbase i40 ; get offset to aggregate element mcpi $r0 $r1 i32 ; copy memory ``` The gas cost was especially problematic, because a single call site could appear in loops, where the six instructions were repeatedly called. The new implementation stores whole `StorageKey`s into the data section, similar to global constants and configurables. Access sites is then compiled to a single pointer access. The new IR for the above example becomes: ``` contract { storage_key storage.scalar = 0x9e0e87bef2e44d9771eb12cfc81e34e4dd6caad55385354757a8898a2c808b61 pub entry fn poke_storage() -> (), !4 { local { b256, u64, b256 } __tmp_arg entry(): // BEGIN OF `storage.scalar` ACCESS v0 = get_storage_key __ptr { b256, u64, b256 }, storage.scalar, !5 // END OF `storage.scalar` ACCESS v1 = get_local __ptr { b256, u64, b256 }, __tmp_arg mem_copy_val v1, v0 v2 = call poke_2(v1) v9 = const unit () ret () v9 } } ``` And in ASM: ``` addr $r0 data_NonConfigurable_0 ; get storage.scalar's address in data section ``` ## Performance Comparisons The gas savings per storage access will, of course, depend on the number of actual calls. To the bytecode size, the optimization deliberately increases the size of the data section, but only for the case of `StorageKey` slots being equal to field ids. Instead of storing only 32 bytes for a single `b256` address, we are now using 32 + 32 + 8 = 72 bytes for storing the whole `StorageKey`, even if the slot address is the same as field id. That's 40 bytes bytecode increase per storage field. However, we are reducing the storage access for 5 opcodes which results in 5 x 4 = 20 bytes of savings for every storage field access. In other words, if a storage field is accessed more then once anywhere in code, there is no size increase, on the contrary, the bytecode size decreases. This is something we expect in real world programs - storage fields being accessed in more then two places, resulting in bytecode size decrease. ### Bytecode size of `should_pass` tests | Test | Before | After | Percentage | |------|--------|-------|------------| | empty_fields_in_storage_struct | 22528 | 21768 | 3.37% | | language/fallback_only | 2008 | 1944 | 3.19% | | language/generics_in_contract | 2448 | 2400 | 1.96% | | static_analysis/cei_pattern_violation_more_complex_logic | 15392 | 15064 | 2.13% | | static_analysis/cei_pattern_violation_storage_map_and_vec | 6424 | 6224 | 3.11% | | static_analysis/cei_pattern_violation_storage_struct_read | 2784 | 2760 | 0.86% | | static_analysis/cei_pattern_violation_storage_var_read | 2952 | 2928 | 0.81% | | static_analysis/cei_pattern_violation_storage_var_update | 2664 | 2648 | 0.60% | | stdlib/storage_vec_insert | 4864 | 4816 | 0.99% | | storage_slot_key_calculation | 4848 | 4856 | -0.17% | | supertraits_for_abis_ownable | 3576 | 3536 | 1.12% | | test_contracts/basic_storage | 32272 | 31720 | 1.71% | | test_contracts/increment_contract | 3168 | 2984 | 5.81% | | test_contracts/storage_access_contract | 28248 | 26720 | 5.41% | | test_contracts/storage_enum_contract | 16128 | 13736 | 14.83% | | test_contracts/storage_namespace | 31248 | 30648 | 1.92% | The slight bytecode size increase in the `storage_slot_key_calculation` test comes from having exactly one `storage.field` access for every storage field. ### Bytecode size and gas usage of Blackjack project | Test | Before | After | Difference (Gas) | | ---- | ------- | ----- | -------------- | | loss_game_test | 49497 | 49181 | 316 | | simple_game_test | 54123 | 53798 | 325 | The bytecode size decreased from 23320 to 22760 bytes, 560 bytes. ### Gas usage of `storage_vec_iter_tests` | Test | Before | After | Gas | Percentage | |------|--------|-------|-----|------------| | storage_vec_field_for_loop_iteration | 163832 | 162916 | 916 | 0.56% | | storage_vec_field_nested_for_loop_iteration | 1395342 | 1392038 | 3304 | 0.24% | ## Checklist - [ ] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-08-29 11:20:40 +10:00
Igor Rončević	9e98c0e9f6	Apply Clippy's uninlined_format_args lint (#7361) ... ## Description This PR improves the readability of `format!`, `write!`, etc. macros by rolling out the Clippy fixes for the `uninlined_format_args` lint. `cargo clippy` started showing this lint after locally switching to Cargo v1.88.0. Additionally, the PR: - replaces a few occurrences of `io::Error::new(std::io::ErrorKind::Other, <msg>)` with `io::Error::other(<msg>)`. - replaces a single occurrence of `if params.iter().any(|&p| p == "all")` with `if params.contains(&"all")`. ## Checklist - [ ] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-08-27 21:57:48 -03:00
João Matos	8be2dae76b	Implement a command to dump impls for a given type (#7322) ... This adds a new `--dump-impls` CLI command that can be used to dump all the recognized trait impls for a given type name. This also extends the compiler diagnostic system to allow the emission of info diagnostics, as previously we could only emit either warnings of errors, which did not fit this use case. ## Description For example, here is the output of `cargo run --bin forc -- build --path _test-case --dump-impls=std::string::String`: <img width="677" height="958" alt="image" src="https://github.com/user-attachments/assets/42aeca94-bbf9-4dff-8bb3-d1a70000999a" /> And for enums: <img width="642" height="285" alt="image" src="https://github.com/user-attachments/assets/ac565fea-9ebe-4f1d-a9a8-d022617d23d0" /> Closes https://github.com/FuelLabs/sway/issues/7286. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-08-26 16:02:16 -07:00
IGI-111	406251e133	Don't duplicate source pointers in spans (#7339) ... ## Description When doing multiple subsequent compilations, such as when running tests or when using the LSP, and reusing engines, in particular the decl engine, an condition can occur when files are loaded a second time and generate new spans that point to a different string than existing spans for that file. This creates a problem when joining spans that point to the same source file but not the same string. This PR adds a new functionality to the source engine, where it will store pointers to source strings (that spans eventually use) and deduplicate them before they can cause this issue. A future PR may want to reuse this facility to prevent unnecessary file loads altogether. Fixes #7338 ## Checklist - [ ] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers.	2025-08-22 04:07:52 +00:00
Daniel Frederico Lins Leite	f036d4c45f	Optimize initialization of array repeat when the initial value is zero (#7299) ... ## Description Continuation of https://github.com/FuelLabs/sway/issues/6860. This PR improves performance of arrays initialized with zero like `[0u16; 5]`. Before, the compiler was initializing the array with `SW` or using a loop, depending on the array size. Now it is being initialized with just one `MCLI`. Example: ```sway #[inline(never)] fn array_repeat_zero_big_u16() -> [u16; 25] { [0u16; 25] } ``` The generated IR will use the local initializer because it has realized the array is initialized with all zeros. ``` fn array_repeat_zero_small_u16_2(__ret_value: __ptr [u64; 5]) -> __ptr [u64; 5], !21 { local [u64; 5] __anon_0 = const [u64; 5] [u64 0, u64 0, u64 0, u64 0, u64 0] entry(__ret_value: __ptr [u64; 5]): v0 = get_local __ptr [u64; 5], __anon_0, !22 mem_copy_val __ret_value, v0 ret __ptr [u64; 5] __ret_value } ``` And this is the generated ASM. ``` pshl i3 ; save registers 16..40 pshh i524288 ; save registers 40..64 move $$locbase $sp ; save locals base register for function array_repeat_zero_small_u16_2 cfei i40 ; allocate 40 bytes for locals and 0 slots for call arguments move $r0 $$arg0 ; save argument 0 (__ret_value) move $r1 $$reta ; save return address addi $$tmp $$locbase i0 ; array initialization - array ptr <----- look here mcli $$tmp i40 ; array initialization - clear mcpi $r0 $$locbase i40 ; copy memory move $$retv $r0 ; set return value cfsi i40 ; free 40 bytes for locals and 0 slots for extra call arguments move $$reta $r1 ; restore return address poph i524288 ; restore registers 40..64 popl i3 ; restore registers 16..40 jal $zero $$reta i0 ; return from call ```` ## Future Optimizations We can simplify the ASM generation for function a lot using the function above as example: ```` pshl i3 pshh i524288 move $$locbase $sp cfei i40 move $r0 $$arg0 move $r1 $$reta addi $$tmp $$locbase i0 mcli $$tmp i40 mcpi $r0 $$locbase i40 move $$retv $r0 cfsi i40 move $$reta $r1 poph i524288 popl i3 jal $zero $$reta i0 ```` - We can merge `ADDI` and `MCLI` into one on `AbstractInstructionSet::constant_propagate`. The optimizer should know that `$$tmp` and `$$locbase` have the same value, and that `addi` here is useless. Another possible option is to allow `constant_propagate` replace `$$tmp` for `$$locbase` in the `mcli` and let DCE remove the `addi`. ``` addi $$tmp $$locbase i0 mcli $$tmp i40 ``` - After this the compiler will see one `mcli` followed by one `mcpi`. Both have the same pointer and the same length. The optimizer should be able to merge it into just one `mcli` ``` mcli $$locbase i40 mcpi $r0 $$locbase i40 ``` - We don't need to save `$reta to `$r1`. This function does not call any other funtion. And we also don't need to move `$r1` back to `$reta`. That would eliminate two instructions... We also don't need to move `$sp` to `$$locbase` for the same reason. And we also don't need to move `$$arg0` to `$r0`. - We also don't need to push and pop all registers. This function is very small and probably only use very few registers. We could eliminate `pshl i3` and `popl i3`, if we just use "high registers" for small functions. After all these optimizations the asm would be ``` pshh i524288 cfei i40 mcli $sp i40 mcpi $$arg0 $sp i40 move $$retv $$arg0 cfsi i40 poph i524288 jal $zero $$reta i0 ```` We can go even further if we realize that `mem[$sp, i40]` is written only once, never read and copied to `mem[$$arg0, i40]`. Which means that we could replace the `mcli` to clear `mem[$$arg0, i40]` directly. That would flag the "local" `mem[$sp, i40]` as never used and we could remove the local entirely. ``` pshh i524288 mcli $$arg0 i40 move $$retv $$arg0 poph i524288 jal $zero $$reta i0 ``` After this we could check if we really need "lowered functions" to have a return value. If not we could remove the `move $$retv $$arg0`. And finish this function on: ``` pshh i524288 mcli $$arg0 i40 poph i524288 jal $zero $$reta i0 ``` And extra optimization would be to realize this function does not write to registers, so it does not need to save and restore them. ``` mcli $$arg0 i40 jal $zero $$reta i0 ``` Of course, that a trivial function like this should be inlined, but I forced to not be inlined so we can exercise some of these optimizations. ## 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.	2025-08-19 16:22:21 +00:00
Daniel Frederico Lins Leite	0339852289	Better observability for the compiler (#7250) ... ## Description Whilst finishing "const generics" I spent a LOT of time trying to find why some cases where not working. Until I found the issue on a "indirect input" for the method `type_check_method_application`. The issue is that some other method was returning a wrong value, and although the solution is not hard, there is no way to fix just this problem, and there is no way to assert this returned value to guarantee that the problem will not return. To start to improve these kind of tests, and help debug problems, this PR start to create a "callback" mechanism that allows anyone using the compiler as a library, this will not be available at the CLI, to inspect and control logging. The integration in out e2e test harness is done by the `test.toml`. ``` category = "run" expected_result = { action = "return", value = 1 } expected_result_new_encoding = { action = "return_data", value = "0000000000000001" } validate_abi = true logs = """ if pkg != "std" && event == "on_before_method_resolution" && method == "len_xxx" { print_args(); trace(true); } if pkg != "std" && event == "on_after_method_resolution" && method == "len_xxx" { print_args(); trace(false); } """ ``` The `harness` framework will not call "logs" for every callback that happens outside of the "std" library. To allow interaction with the harness itself, some commands are available: - `print_args` print all the available arguments for that event on the "snapshot"; - `trace` enables/disables trace level logging, that also end up in the "snapshot". In the example above, we will generate the following snapshot: ``` --- source: test/src/e2e_vm_tests/harness_callback_handler.rs assertion_line: 14 --- on_before_method_resolution: FromModule { method_name: len_xxx }; Regular([]); S<unresolved T -> u64, N -> 3> before get_method_safe_to_unify: S<unresolved T -> u64, N -> 3> len_xxx<N -> None>(self: unresolved Self -> S<unresolved T -> T, N -> None>): u64 -> u64 after get_method_safe_to_unify: S<unresolved T -> u64, N -> 3>; len_xxx<N -> 3>(self: unresolved Self -> S<unresolved T -> u64, N -> None>): u64 -> u64 on_after_method_resolution: FromModule { method_name: len_xxx }; Regular([]); S<unresolved T -> u64, N -> 3>; len_xxx<N -> 3>(self: unresolved Self -> S<unresolved T -> u64, N -> None>): u64 -> u64; S<unresolved T -> u64, N -> 3> on_before_method_resolution: FromModule { method_name: len_xxx }; Regular([]); S<unresolved T -> u64, N -> 3> before get_method_safe_to_unify: S<unresolved T -> u64, N -> 3> len_xxx<N -> None>(self: unresolved Self -> S<unresolved T -> T, N -> None>): u64 -> u64 after get_method_safe_to_unify: S<unresolved T -> u64, N -> 3>; len_xxx<N -> 3>(self: unresolved Self -> S<unresolved T -> u64, N -> None>): u64 -> u64 ``` The important part is that the problem I want to fix it's there. On the line of "get_method_safe_to_unify", the "self" parameter const generic argument "N" is not being materialized, although the method resolution pass started with a fully materialized type. With this callback machinery it becomes easier to debug the problems, and possible to generate asserts to internal methods. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers.	2025-07-18 07:24:32 +00:00
Hannes Karppila	1ac3514f50	Bump fuel deps (#7228) ... ## Description Bumps fuel-vm, fuel-core fuels-rs and forc-wallet to latest versions. Upgrades Rust to 2021 edition. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - I believe this is non-breaking from user code perspective but I'm not too sure about that - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: z <zees-dev@users.noreply.github.com> Co-authored-by: zees-dev <63374656+zees-dev@users.noreply.github.com> Co-authored-by: JoshuaBatty <joshpbatty@gmail.com> Co-authored-by: IGI-111 <igi-111@protonmail.com>	2025-06-23 13:05:53 +04:00
Igor Rončević	f03d5ecdb0	Compile panic expression to ABI error codes (#7118) ... ## Description This PR is the final step in implementing the `panic` expression and the ABI errors, as defined in the [ABI Errors RFC](https://github.com/FuelLabs/sway-rfcs/blob/master/rfcs/0014-abi-errors.md). The PR generates the `errorCodes` section in the ABI, like, e.g.: ``` "errorCodes": { "18446744069414584320": { "pos": { "pkg": "my_lib@1.2.3", "file": "src/lib.rs", "line": 42, "column": 13 }, "logId": null, "msg": "Error message." }, "18446744069414584321": { "pos": { "pkg": "my_contract", "file": "src/main.rs", "line": 21, "column": 34 }, "logId": "4933727799282657266", "msg": null } } ``` If the `panic` argument is a string slice that can be const-evaluated, the `msg` field of the corresponding error code is generated, and a log is not emitted. The string itself is stored only within the ABI JSON, and is not included into the generated bytecode. Additionally, the PR: - provides a common infrastructure for obtaining a `SourceLocation` from a `Span`. This is currently used in the implementation of the `__dbg` intrinsics and the `panic` expression. - improves filtering of `forc` outputs in snapshot tests by supporting regular expressions. The `grep` command is renamed to `regex` to avoid confusion with piping the actual `grep` CLI command. Partially addresses #6765. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: hal3e <git@hal3e.io>	2025-05-27 20:32:40 +10:00
Igor Rončević	40cffb2975	Parse raw identifiers (r#<identifier>) in expressions (#7137)	2025-05-01 10:59:53 +01:00
João Matos	173b65b335	Upgrade CI and fix Clippy issues with Rust 1.86.0 (#7127) ... ## Description As title says. --------- Co-authored-by: IGI-111 <igi-111@protonmail.com>	2025-04-29 12:04:03 +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
Daniel Frederico Lins Leite	f607a674e3	More Sway compiler optimizations (#7093) ... ## Description This PR is a prequel to https://github.com/FuelLabs/sway/pull/7015, trying to optimize the compiler to alleviate the hit of having more items, `impl` etc... We have here two optimizations: 1 - We spend a lot of time counting newlines when converting byte offsets to `LineCol`. Now, we calculate line offsets just once, and use binary search later to find which line a byte offset is at. 2 - `QueryEngine::get_programs_cache_entry` was cloning the whole `TyProgram`. That is why `did_change_with_caching` was always getting worse, as the program was increasing in size. Now all compilation stages are behind `Arc`, which makes the `clone` free. ## Analysis Putting a `dbg!(...)` like the image below, and calling `counts` (https://github.com/nnethercote/counts). ``` cargo bench -- traverse 2>&1 | grep "sway-types/src/span.rs:29:9" | counts ```  I get the following results: ``` 972102 counts ( 1) 156720 (16.1%, 16.1%): [sway-types/src/span.rs:29:9] self.pos = 0 ( 2) 15900 ( 1.6%, 17.8%): [sway-types/src/span.rs:29:9] self.pos = 104 ( 3) 15840 ( 1.6%, 19.4%): [sway-types/src/span.rs:29:9] self.pos = 107 ( 4) 2280 ( 0.2%, 19.6%): [sway-types/src/span.rs:29:9] self.pos = 19281 ( 5) 2280 ( 0.2%, 19.9%): [sway-types/src/span.rs:29:9] self.pos = 19285 ( 6) 2280 ( 0.2%, 20.1%): [sway-types/src/span.rs:29:9] self.pos = 19287 ( 7) 2280 ( 0.2%, 20.3%): [sway-types/src/span.rs:29:9] self.pos = 19292 ( 8) 2280 ( 0.2%, 20.6%): [sway-types/src/span.rs:29:9] self.pos = 19323 ( 9) 2280 ( 0.2%, 20.8%): [sway-types/src/span.rs:29:9] self.pos = 19327 ( 10) 2280 ( 0.2%, 21.0%): [sway-types/src/span.rs:29:9] self.pos = 19329 ( 11) 2280 ( 0.2%, 21.3%): [sway-types/src/span.rs:29:9] self.pos = 19334 ( 12) 870 ( 0.1%, 21.4%): [sway-types/src/span.rs:29:9] self.pos = 4285 ... ``` This means that `line_col` is being called 972k times. 16% is for position zero, which should be trivial. The rest will iterate the whole file source code to count number of lines. Making the real complexity of the work here something like `O(qty * self.pos)`. And some values of `self.pos` are not trivial at all. ## Checklist - [ ] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers.	2025-04-21 12:36:15 -07:00
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
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
Igor Rončević	8b3d822112	Implement trees visitors and migrations for TryFrom<Bytes> for b256 (#7005) ... ## Description This PR: - extends infrastructure for writing migrations that modify individual expressions and do not need access to a broader scope. It does that by providing lexed and typed tree visitors. Visiting lexed and typed tree is implemented to the level needed to write the migration for `impl TryFrom<Bytes> for b256`. - implements the migration for `impl TryFrom<Bytes> for b256` as explained in #6994. Adding `#[cfg(experimental_try_from_bytes_for_b256 = true)]` to the `impl TryFrom<Bytes> for b256` revealed that there existed already an `impl TryFrom<Bytes> for b256` in `std::primitive_conversions::b256`. Due the lack of trait coherence there was no any errors when it was re-implemented in `std::bytes`. This PR marks the existing impl in `std::primitive_conversions::b256` with `#[cfg(experimental_try_from_bytes_for_b256 = false)]` so that it will be removed in the next breaking release, in favor of the new impl in `std::bytes`. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-03-11 11:20:13 +11:00
João Matos	4b99ee5df5	Add ProgramId to root module. (#6959) ... ## Description Adds `ProgramId` to root module to be used in the trait coherence work. Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2025-02-27 05:24:37 +00: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
jjcnn	2b2ce517d1	Refactor the module structure of the namespace module (#6291) ... ## Description Fixes #5498. This PR contains a major refactoring of the namespace module, which is responsible for keeping track of the symbol bindings in the program. The refactoring is intended to reduce memory allocation during compilation, and also fixes a number of minor bugs related to path resolution. ### Advice to the reviewer: I recommend reviewing this PR in 3 steps: 1. Review the PR description. If something in the description is unclear, then leave a review comment, and I will try to address the issue. The code changes will be significantly easier to review once you get the overall idea of what is happening. 2. Review the files `sway-core/src/semantic_analysis/namespace/root.rs`, `sway-core/src/semantic_analysis/namespace/namespace.rs` and `sway-core/src/language/call_path.rs`. These files contain the major datastructure changes, and if anything in those files needs to be addressed, then there is limited value in reviewing the rest of the code changes. 3. Review the remaining files. These code changes are all consequences of the changes in step 2, so it shouldn't take too much time, even though there are quite a few changes. ### Remaining issues No remaining issues except for what reviwers bring up. ### Breaking changes As illustrated by one of the test cases the PR makes paths to external libraries such as `::core::codec::*` illegal. This is a bugfix rather than a change in behavior (the correct path is `core::codec::*`), but may require updates of existing programs. Additionally, the visibility check for modules was broken, so some modules declared using `mod x` would have incorrectly been considered public even though it should have been declared `pub mod x`. Again, this is a bugfix rather than a change of behavior, but may require updates of existing programs. ### Changes made by this PR _Representation of the dependency graph_ (main file: `sway-core/src/semantic_analysis/namespace/root.rs`) Previous: External libraries were represented as submodules of every module in the program. This meant that every module in every external package was cloned for every module in the program, and recursively so, since external libraries could also have dependencies that required clones for every module. In particular, `std` has `core` as a dependency: ``` core: "" (lib.sw) / / | \ \ primitives raw_ptr raw_slice slice ... std: "" (lib.sw) / / | \ \ core constants vec primitive_conversions ... / / | \ \ | | | | \ ... core core core b256 ... / / | \ \ / / | \ \ / / | \ \ | ... ... ... core / / | \ \ ... External library: "" (lib.sw) / / | \ core std submodule ... / / | \ \ / \ / \ \ ... core ... core std ... / / | \ \ / / | \ \ / \ ... ... core ... / / | \ \ Main program: "" (main.sw) / / | \ core std external library submodule / / | \ \ / \ / \ \ / | \ ... core ... core std submodule core std external library / / | \ \ / / | \ \ / \ / \ / \ / \ / | \ ... ... core ... ... ... ... core ... core std ... / / | \ \ / \ / \ / \ ... ... core ... / \ ... ``` Changes in this PR: External libraries are now represented only at the package root. The root module is given the same name as the package so that paths beginning with the package name can be resolved as a module path. If multiple libraries depend on the same external library, then they each contain a clone (this can be resolved a at later stage by introducing a global table of libraries). ``` core: core (lib.sw) / / | \ \ primitives raw_ptr raw_slice slice ... std: std (lib.sw) ====== externals =====> core / / | \ \ / | | \ ... constants vec primitive_conversions ... / \ b256 ... External library: external_lib (lib.sw) === externals ===> core / \ / / | \ \ submodule ... ... | ... std == externals => core / / | \ \ / / | \ \ ... ... Main program: main_program (main.sw) === externals ===> core / \ / / | \ \ submodule ... ... | ... std == externals => core / / | \ \ / / | \ \ ... ... extenral_lib == externals => core / / | \ \ / / | \ \ ... ... std == externals => core / / | \ \ / / | \ \ ... ... ``` Reasoning: This change dramatically reduces the amount of cloning of external libraries. The cloning is not eliminated completely, since multiple libraries may have the same library as a dependency (e.g., `core` is used as a dependency for both the program and `std`, so if the program depends on `std`, then there will be two clones of `core` in the tree). The remaining cloning can be eliminated by introducing a global table of libraries, which should be doable without making significant changes to the path resolution algorithm. _Callpath representation_ (main file: sway-core/src/language/call_path.rs) Previous: Paths to externals were considered relative to current module. This worked because all externals existed a submodules of every module. Paths inside the current package were ambiguous, and were either interpreted relative to current module or relative to the root module. The root module did not have a name, so the empty path was used to indicate the root module. Now: All full paths start with the name of the package, which is also the name of the root module. If the first identifier is not the name of the current package, then we look in the externals of that package, and if the name isn't found there we throw an error. Note that the name of an external is defined in Forc.toml, and may be different from the name used inside the external library (e.g., a library may call itself `X`, but a project may use `X` as an external under the name `Y`). This means that any path that escapes from a library must have its package name changed. Reasoning: This is all a conseqence of the change to the representation of the dependency graph. We need to be able to the rely on the package name in order to resolve the path within the correct pacakge. Additionally, if a path escapes from a dependency to a dependent, then the package name must be changed to what the package is called in the dependent. _CallPath.callpath_type_ (main file: sway-core/src/language/call_path.rs) Previous: The CallPath struct contained a flag `is_absolute`, which, if set, was used to mean two different things. For parsed paths it was used to signal that the path started with `::`, i.e., that the path should be resolved relative to the current package root. For paths generated during typechecking the flag was used to indicate that the path was a full path, i.e., that it should either be resolved relative to the current package root or that it was a path to an external library. Now: `is_absolute` has been replaced with `callpath_type`, which has 3 possible values: `RelativeToPackageRoot`, which indicates that the path started with `::`, `Full`, which indicates that the path starts with the package name, and `Ambiguous`, which indicates that the path should either be resolved relative to the current module, or that it is a full path referring to an external library. Reasoning: A path has 3 different states, so a boolean flag is not sufficient to represent all states. _Path representation_ (main file: sway-core/src/language/call_path.rs) Previous: Full paths always pointed to the module containing the declaration of the thing that the path resolves to. Now: Full paths point to a module where the suffix is bound. This may not be the module containing the declaration of the thing the suffix is bound to, because the binding may be the result of an import. The trait map is special in that the path to the actual declaration is used as a key in the map, so for traits we use the canonical path, which point to the module where the declaration resides. Reasoning: The previous definition of full paths required a duplication of the symbol resolution algorithm in order to construct the full path, and it was getting very difficult to maintain. In the vast majority of cases we only need the full path to indicate somewhere where the symbol can be resolved, and don't actually need to know where the declaration resides. In the few cases where we do need to know the path to the declaration (the trait map uses these paths as keys) we can generate the canonical path by first converting to the full path, and then resolving the path and using the path stored with the binding in the lexical scope, since this is the path to the actual declaration. Additionally, the previous solution was only able to generate full paths for paths where the suffix is an identifier - for other suffix types we could not generate a full path. This has now been changed so that we can generate full paths for all paths, although canonical paths are still restricted to paths with an identifier as the suffix. This also moves us closer to a situation where we can represent semantic (canonical) paths separately from syntactic callpaths. _Namespace.init removed_ (main file: sway-core/src/semantic_analysis/namespace/namespace.rs) Previous: The `Namespace` struct contained an `init` module which was used as a template for new modules, a clone of which was created every time the collection pass or the typechecker entered a submodule. This template contained all external libraries as submodules, as well as (for contract pacakges) a (new) declaration of `CONTRACT_ID`. Now: The `init` module has been removed. When the collection pass or the typechecker enters a new submodule, `Namespace` creates a new `Module` (if none exists yet for the relevant submodule), and populates it with implicit imports (`core::prelude::*` and `std::prelude::*`, and for contract packages `CONTRACT_ID`). Reasoning: The current solution makes it significantly clearer what is in a new `Module` object. Additionally, the declaration of `CONTRACT_ID` is no longer duplicated in each module - it is now declared once in the root module, and imported everywhere else. _namespace encapsulation_ (main file: sway-core/src/semantic_analysis/namespace/namespace.rs) Previous: The `Namespace` struct contained methods to extract the underlying datastructures in the `namespace` module. Now: An attempt has been made to encapsulate the `namespace` module a little bit more, so that changes and lookups to the datastructures in the `namespace` module are done by calling methods on the Namespace struct rather than letting the caller extract the datastructures and manipulating them directly. Reasoning: When the datastructures are manipulated in many different places it makes it very hard to track down all the places that need to be changed when making changes to the datastructure. The current solution is not perfect, but it does encapsulate things a bit better than before. ### Minor changes and improvements A few minor improvements have been made: - A compilation unit (`core`, `std`, etc.) is now referred to as a _package_. (Note: The `Root` struct should probably be renamed to `Package` for consistency) - The visibility check for path resolution in `type_resolve.rs` had to be updated because path resolution was changed. The current version is not perfect, but it does improve the faulty check we had before. - `TyModule` so far contained a clone of the `Namespace` struct in the state it was in when typechecking of the relevant module was done. The `Namespace` object was never used except for the one in the root module, so I have moved the `Namespace` clone to `TyProgram`, thus eliminating quite a bit of unnecessary cloning (the Namespace struct owns the current package `Root` object, and thus cloning the `Namespace` struct clones the entire dependency graph). For error handling purposes in sway-lsp we save the current namespace in `TypeCheckFailed` rather than in `TyModule`, which also significantly reduces memory allocation during compilation. ### Updated tests A number of tests have been updated for various reasons: - Improved or changed error messages - Module visibility was not checked correctly, so some tests had to have certain submodules made public. - In once case, `core::str_slice` was referenced using the path `::core::str_slice`. This is invalid, but since `core` used to be treated as a submodule of every module in the program, the path resolved anyway. (This also shows that the invalid paths in issue #5498 are now actually treated as invalid - I have not added regression tests of that issue, since it seems unlikely that we will reintroduce the bug). ### Unresolved issues - The `Namespace` struct is cloned before the symbol collection phase. This is expensive, since the `Namespace` struct at that point contains the entire dependency graph (minus the modules of the current package). Ideally we would like the symbol collection phase and the typechecker to use the same `Namespace` struct, but at the moment the Module struct is unable to perform updates from parsed to typechecked declarations, so this isn't possible. The cloning happens in `sway-core/src/lib.rs` and `sway-core/src/semantic_analysis/namespace/contract_helpers.rs`. Once we represent externals as a global table we should be able to change the `Root.externals` map to only use references into the global table, which will make the cloning step much cheaper. - `contract_helpers.rs` throws a regular compiler error if typechecking fails, but that should be an ICE, since it is generated code that is failing to typecheck. - Paths may in some cases escape from external packages to the current package. If this happens across multiple packages, then this may result in the path no longer being valid. For instance, if A depends on B, which in turn depends on C, then a path may escape from C via B into A, but since A does not have C as a direct dependency, then the path can no longer be resolved. This again can be fixed once we introduce a global table of externals. - The visibility check in `type_resolve.rs` is insufficient, because it doesn't handle enum variants and associated types correctly. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: João Matos <joao@tritao.eu> Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2025-01-17 00:55:37 +00:00
Daniel Frederico Lins Leite	77d583aba7	Show error when contract method names conflict (#6782) ... ## Description Today, contract call uses the method name to identify which contract method to call. That means that a contract cannot have multiple methods with the same name. That can happen when a contract implements traits:  A lot of the lifetime changes were caused by clippy. ## Checklist - [ ] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] 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-01-15 15:27:25 +01:00
Igor Rončević	23576769d1	Refactor swayfmt to support arbitrary lexed trees (#6806) ... ## Description This PR refactors `swayfmt` to be able generate code from arbitrary lexed trees. Arbitrary means a lexed tree that can be fully or partially created in-memory by manipulating the tree structure in code. It does not need to necessarily be backed by source code. This is needed to be able to reuse `swayfmt` for generating source code from tools that analyze and modify Sway code, as explained in #6779. This PR makes the `swayfmt` independent of spans backed by the source code, by doing the following changes: - Keywords are rendered by using theirs `AS_STR` associated constants. - The `Token` trait is extended with the `AS_STR` associated constant, and tokens are rendered by using that constant. - `Ident`s are rendered by using theirs `as_str()` methods. This method takes the textual implementation from `Ident::name_override_opt` if it is provided, and ignores the span in that case. - `Literal`s are rendered based on the literal value and not their spans. The exception are numeric literals that do not have empty spans. Those are considered to be backed by source code and are rendered as written in code, e.g., `1_000_000u64`. The PR also fixes some existing bugs in `swayfmt`: - `use path::{single_import,};` will be formatted as `use path::single_import;` - `use path::{a,b,};` will be formatted as `use path::{a, b};` - partial addresses #6802 by rendering annotations for final values. - partial addresses #6805 by properly rendering final values, but still not using the expected field alignment. The PR also removes the `path` parameter from the `parse_file`. It was used only to provide an unnecessary dummy `source_id` which was always pointing to the package root file. Closes #6779. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-01-07 12:55:03 +01:00
Joshua Batty	37205445ab	Implement Serde for AstNode types (#6605) ... ## Description This PR extends Serde support across all AstNode-related types, building upon the partial implementation from #4193. Key points: * Adds both `Serialize` and `Deserialize` trait implementations to all relevant types. * Prepares for upcoming language server features that will serialize/deserialize types between keystrokes. * Important: The type interface in the compiler is not yet stable. This implementation is intended for temporary serialization/deserialization work, not for persistent storage. ## Checklist - [x] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2024-12-02 09:48:45 +11:00
Igor Rončević	73e1a7a803	Rewrite TypeEngine for performance, robustness, and simplicity (#6613) ... ## Description This PR implements a major rewrite of the `TypeEngine`. The rewrite: - significantly improves overall compilation performance. The compilation time of the real-world [Spark Orderbook workspace](https://github.com/compolabs/orderbook-contract) got **reduced from 8.99 to 5.94 seconds**, and the memory consumption from **3.32 to 1.78 GB**. - provides robust API for inserting types, related to the usage of the `source_id` (see: #5991). The new API forbids not providing `source_id`s or providing semantically questionable or non-optimal ones. - introduces simpler, much less verbose, API for inserting types. The PR also removes the obsolete and unused `TypeInfo::Storage`. The PR **does not address** the following: - The `TypeEngine`'s "garbage-collection-(un)friendlines" (see: #6603). - The handling of the `TypeInfo::Custom` and `TypeInfo::TraitType` types within the `TypeEngine` (see: #6601). - The number of interactions with the `TypeEngine`. E.g., removing unnecessary insertions after `resolve()`ing or `monomorphyze()`ing types will be done as a part of `DeclEngine` optimization. Closes #5991. ## Shareable types The PR formalizes the notion of a _shareable type_ within the `TypeEngine` (strictly speaking, a shareable `TypeInfo`). A shareable type is a type that is both: - _unchangeable_: it, or any of its parts, cannot be replaced during the unification or monomorphization. - and _undistinguishable by annotations_: it doesn't carry any additional information (annotations) that could differ it from another instance of `TypeInfo` that would, purely from the type perspective, be a same type. E.g., `u64` or `MyStruct<u64, bool>` are unchangeable while `Numeric`, `Unknown` or `MyStruct<T1, T1>` are changeable. E.g., in this example, `a` and `b` have the same type, `[u64; 2]` but those two types differ in spans assigned to the "u64"s and the "2"s, and are treated as different within the `TypeEngine`, and thus as non-shareable. ``` let a: [u64; 2] = [1, 1]; let b: [u64; 2] = [2, 2]; ``` Shareability of a type is crucial for reusing the `TypeSourceInfo` instances within the type engine. Shareable types can be given different `TypeId`s without the need to newly allocate a `TypeSourceInfo`. ## Performance improvements The cummulative effect of the performance improvements on the compilataion of the real-world [Spark Orderbook workspace](https://github.com/compolabs/orderbook-contract) is given below. The compilation means the frontend compilation, up to the IR generation (`forc check`). **Compilation time** ``` Before: Time (mean ± σ): 8.995 s ± 0.297 s [User: 7.126 s, System: 1.289 s] Range (min … max): 8.675 s … 9.262 s 3 runs After: Time (mean ± σ): 5.945 s ± 0.517 s [User: 4.749 s, System: 0.768 s] Range (min … max): 5.349 s … 6.280 s 3 runs ``` **Memory consumption** ``` --------------------------------------------------------- total(B) useful-heap(B) extra-heap(B) --------------------------------------------------------- Before: 3,316,786,808 3,237,317,383 79,469,425 After: 1,784,467,376 1,743,772,406 40,694,970 ``` ### Applied optimizations: - **Replacement of expensive `insert` calls with compile time constants for built-in types.** Built-in types like `!`, `bool`, `()`, `u8`, etc. are inserted into the engine at its creation at predefined slots within the `slab`. The `id_of_<built-in-type>` methods just return those predefined `TypeId`s, effectively being compiled down to constants. The calls like `type_engine.insert(engines, TypeInfo::Boolean, None)` are replaced with maximally optimized and non-verbose `type_engine.id_of_bool()`. - **Elimination of extensive creation of `TypeSourceInfo`s for `TypeInfo::Unknown/Numeric`s.** `Unknown` and `Numeric` are inserted into the engine ~50.000 times. Each insert used to create a new instance of `TypeSourceInfo` with the `source_id` set to `None`. The optimization replaces those ~50.000 instances with two predefined singleton instances, one for `Unknown` + `None` and one for `Numeric` + `None`. (Note that when implementing #6603, we will want to bind also `Unknown`s and `Numeric`s to `source_id`s different then `None`, but we will still want to reuse the `TypeInfo` instances.) - **Elimination of extensive temporary heap-allocations during hash calculation.** The custom hasher obtained by `make_hasher` required a `TypeSourceInfo` to calculate the hash and it was called every time the `insert` was called, ~530.000 times. Getting the `TypeSourceInfo` originally required cloning the `TypeInfo`, which depending on the concrete `TypeInfo` instance could cause heap allocations, and also heap-allocating that copy within an `Arc`. Hash was calculated regardless of the possibility for the type to be stored in the hash map of reusable types. The optimization removed the hashing step if the type is not shareable, removed the cloning of the `TypeInfo` and introduced a custom `compute_hash_without_heap_allocation` method that produced the same hash as the `make_hasher` but without unnecessary temporary heap-allocations of `TypeSourceInfo`s. - **Replacement of `TypeSourceInfo`s within the hash map with `Arc<TypeSourceInfo>`s.** The hash map unnecessarily required making copies of reused `TypeSourceInfo`s. - **Introducing the concept of a _shareable type_ and rolling it out for all types.** Previously, the engine checked only for changeability of types by using the `TypeInfo::is_changeable` method. The implementation of that method was extremely simplified, e.g. treating all structs and enums with generic arguments as changeable even if they were fully monomorphized. This resulted in over-bloating the engine with type instances that were actually unchangeable, but considered to be changeable. Also, strictly seen, the unchangeability (during unification and monomorphization) is not the only necessary criteria for reuse (or sharing) a type within the engine. Another important aspect is, as explained above, the _differentiability by annotations_. The PR introduces the notion of a _shareable type_ which is both unchangeable and not differentiable by annotations. The optimization takes advantage of such types by storing them only once per `source_id`. - **Elimination of extensive unnecessary inserts of new types during `replace()` calls.** When `replace()`ing types during unifications, a new `TypeSourceInfo` instance was created for every replacement, ~46.000 times. This meant a heap-allocation of the `TypeSourceInfo` (16 bytes) and the `Arc`-contained `TypeInfo` (232 bytes), even if the replaced type was shareable and already available in the type engine. The optimization now reuses an already existing shareable type if available. ## Robustness related to `source_id`s The issues we had with properly providing the `source_id` in the `insert` method are explained in #5991. This PR removes the `source_id` from the new public API and calculates it internally within the engine, based on the type being inserted. This makes inserting of types both more robust and less verbose and eliminates the possibility of providing a semantically wrong `source_id`. Note that the calculation of an optimal `source_id` done within the engine fully corresponds to the "calculations" we currently have at call sites. E.g., when inserting enums, previously we always had to write `type_engine.insert(engines, TypeInfo::Enum(decl_id), enum_decl.span.source_id())`. Fetching the `source_id` from the enum declaration is now done within the `insert_enum` method: `type_engine.insert_enum(engines, decl_id)`. Note that for certain types we will want to change the current behavior and either provide a `source_id` or pick a more suitable one. E.g, even when inserting `Unknown`s, we will want to have `source_id`s, if possible. This will be done in #6603, but again, together with providing a robust API that will be difficult to misuse. ## Simplicity As already mentioned in some of the examples above, the new `id_of_<type>()` and `insert_<type>` methods provide much simpler and less verbose API to use. Introducing those methods remove a lot of boilerplate code from the callers. Also, the individual `insert_<type>` methods are additionally optimized for inserting the particular type. The common `insert` method is intended to be used only in cases where the inserted `TypeInfo` is not known at the call site. Here are some examples of the new API versus the existing one: |Before|After| |------|-----| | `type_engine.insert(engines, TypeInfo::Tuple(vec![]), None)` | `type_engine.id_of_unit()` | | `type_engine.insert(engines, TypeInfo::Unknown, None)` | `type_engine.new_unknown()` | | `type_engine.insert(engines, TypeInfo::UnsignedInteger(IntegerBits::SixtyFour), None)` | `type_engine.id_of_u64()` | For more complex types, like, e.g., `TypeInfo::Tuple`, the difference in inserting is even more prominent, as can be seen from the diffs of numerous code lines deleted in this PR. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: Joshua Batty <joshpbatty@gmail.com> Co-authored-by: João Matos <joao@tritao.eu>	2024-11-06 09:03:21 +00:00
Daniel Frederico Lins Leite	ddb505d263	migrate encoding v1 to sway-features (#6586) ... ## Description This PR starts the implementation of https://github.com/FuelLabs/sway-rfcs/blob/master/rfcs/0013-changes-lifecycle.md. ## CLI flags Now, all `CLI`s, including our tests, support two new arguments ``` ... --experimental <EXPERIMENTAL> Comma separated list of all experimental features that will be enabled [possible values: new_encoding, storage_domains] --no-experimental <NO_EXPERIMENTAL> Comma separated list of all experimental features that will be disabled [possible values: new_encoding, storage_domains] ... ``` Experimental features can also be enabled inside `Forc.toml` for workspaces and individual projects. ``` experimental = { encoding-v1 = true } ``` And can be enabled using environment variables: ``` FORC_NO_EXPERIMENTAL=feature_a,feature_b FORC_EXPERIMENTAL=feature_c forc build ... ``` These configurations are applied in a very specific order to allow them to be overwritten. The order from the weakest to the strongest is: 1 - Workspace `TOML` 2 - Project `TOML` 3 - CLI 4 - Environment variables. The rationale is: 1 - We want an easy way to enable and/or disable a feature for the whole workspace; 2 - But we want to allow projects to overwrite these features, when needed. These two are the suggested approach to configure experimental features, but we also want to allow someone to easily turn on or off features to test something in particular. For that one can use the CLI flags; and in the specific case one does not have access to the CLI, for example, when one of the `SDK` is compiling the code, one can still completely overwrite the `TOML` files using environment variables. We are also applying the "no experimental" first. This is to allow the use case of exactly controlling which features will be enabled and disabled. In this case one can use the "meta-feature" `all` to disable everything and enable only the desired features. For example: ``` FORC_NO_EXPERIMENTAL=all FORC_EXPERIMENTAL=new_encoding your_command.... ``` ## Test for "-h" This PR also introduces snapshot tests for "-h" for all forc commands at https://github.com/FuelLabs/sway/pull/6586/files#diff-20a5e677d2ae9266a2247739b6a473d2ad0c627955187d668822e7d194f8e940 ## Multiple test.toml This PR also enables the use of multiple `test.toml`. Now each `test.toml` will be a different test, allowing the same code to be compiled and asserted differently. For example, `main_args_empty` has two files: the normal `test.toml` and a new `test.encoding_v1.toml`. One has `new_encoding` enabled and the other disabled. When a `test.toml` file has the `experimental` field, we do not use fields with `_new_encoding` suffix anymore, making these files simpler: test.toml: ```toml category = "run" # (1336, 1) script_data = "0000000000000538 0000000000000001" expected_result = { action = "return", value = 1337 } validate_abi = true experimental = { encoding_v1 = false } ``` test.encoding_v1.toml ``` script_data = "0000000000000538 0000000000000001" expected_result = { action = "return_data", value = "0000000000000539" } experimental = { new_encoding = true } ``` Test tomls with a suffix use `test.toml` as a base. So we do not need to repeat every field in them. Now when we run a test, we will see two tests instead of just one: ``` ... Testing should_pass/language/main_args/main_args_empty (test.encoding_v1.toml) ... ok Testing should_pass/language/main_args/main_args_empty (test.toml) ... ok ... ``` ## Conditional compilation It is also possible to use conditional compilation using these experimental features. Examples can be found inside `sway-lib-std`. ```sway #[cfg(experimental_new_encoding = true)] pub fn assert_eq<T>(v1: T, v2: T) { ... } ``` ## Checklist - [ ] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: IGI-111 <igi-111@protonmail.com>	2024-10-28 11:34:03 +01:00
Alfie John	ab1e030f98	Move all crate dependencies to the workspace Cargo.toml (#6179) (#6563) ... ## Description For #6179, PR #6501 kept bumping into errors as it was doing too many things, so I've split that PR into multiple PRs. This is the first, and the only thing it does is move all of the various `Cargo.toml` dependencies into the single workspace `Cargo.toml`. Future PRs will: - Update dependency versions - Update code that breaks from the version bumps ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2024-09-21 09:48:34 +10:00
Joshua Batty	cba9a005ef	chore: bump to v0.63.6 (#6556) ... ## Description Bumps repo to v0.63.6 waiting on #6555	2024-09-18 12:45:46 -07:00
Kaya Gökalp	31a1d6f983	chore: bump to v0.63.5 (#6508) ... ## Description Bumps repo to v0.63.5	2024-09-06 18:31:11 +00:00
IGI-111	2538442a67	Bump to v0.63.4 (#6503)	2024-09-05 20:30:44 +02:00
Joshua Batty	f55c81cce6	Bump to v0.63.3 (#6483)	2024-08-28 23:57:55 -07:00
IGI-111	a9e83955bc	Bump to v0.63.2 (#6476)	2024-08-28 23:06:10 +02:00
Marcos Henrich	4698d37b91	Fixes Numeric type propagation (#6461) ... ## Description To fix the Numeric type propagation we now do the type checking of code blocks twice, first to collect all the unification and second to unify the types of a previous namespace with the variable declarations types of the current namespace. This change incurs a performance drop in the compilation time. The benchmark `compile` takes 25% more time to run. This can be improved significantly by using LexicalScopes instead of cloning the whole namespace on each scope. Fixes #6371 ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: IGI-111 <igi-111@protonmail.com>	2024-08-28 18:57:19 +00:00
Kaya Gökalp	169f91ae0a	Bump version to 0.63.1 (#6438) ... ## Description Bumps version to 0.63.1	2024-08-19 20:34:40 +00:00
Sophie Dankel	da9b323070	chore: bump to 0.63.0 (#6421) ... ## Description To be merged after https://github.com/FuelLabs/sway/pull/6250 ## 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: Brandon Kite <brandonkite92@gmail.com> Co-authored-by: IGI-111 <igi-111@protonmail.com>	2024-08-19 18:37:36 +02:00
Daniel Frederico Lins Leite	a82e954c17	Better checks at type_check_analyze (#6410) ... ## Description Fix https://github.com/FuelLabs/sway/issues/6342 and https://github.com/FuelLabs/sway/issues/6370. https://github.com/FuelLabs/sway/issues/6342 occurs because when the type checker unifies `Numeric` with an unsigned integer, it never checks if the original literal actually fits into the new "unified" type. https://github.com/FuelLabs/sway/issues/6370 happens because we never go back to the array and check if every item actually is valid. This PR is now doing these two tests at `type_check_analyze`. ## 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>	2024-08-16 01:19:07 +00:00
IGI-111	e9cdaacaf1	Remove support for namespace attribute (#6279) ... ## Description Namespace annotation is no longer supported and has been replaced by namespacing syntax. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2024-07-19 13:53:59 +02:00
IGI-111	efda0397c7	Bump to v0.62.0 (#6276)	2024-07-18 09:13:09 +10:00
Sophie Dankel	e1b1c2bee7	Bump to v0.61.2 (#6213) ... ## Description Includes critical fix https://github.com/FuelLabs/sway/pull/6212 ## 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.	2024-07-03 15:24:12 -07:00
IGI-111	d86bb86369	Bump to v0.61.1 (#6207)	2024-07-02 23:03:30 +02:00
IGI-111	4b4fb53eb2	Bump to v0.61.0 (#6144)	2024-06-19 15:40:51 +04:00
Marcos Henrich	e30497caaa	Storage name based slots and namespaces. (#6064) ... ## Description With this change storage keys will have a hash based on: `sha256("storage::<storage_namespace_name1>::<storage_namespace_name2>.<storage_field_name>"` or a given key. A key can be provided by using the `in` keyword in a storage field as such: ``` storage { a in 0x02dac99c283f16bc91b74f6942db7f012699a2ad51272b15207b9cc14a70dbae: u64 } ``` Or by using a const expression: ``` const C1 = 0x02dac99c283f16bc91b74f6942db7f012699a2ad51272b15207b9cc14a70dbae; storage { a in C1: u64 } ``` StorageKey.field_id is now based on: `sha256("storage::<storage_namespace_name1>::<storage_namespace_name2>.<storage_field_name>.<struct_field_name1>.<struct_field_name2>")` Nested storage namespaces such as the following are now supported. ``` storage { my_namespace1 { my_namespace2 { b:u64 = 1, } } } ``` A deprecated warning is now thrown when the attribute `#[namespace(ns)]` is used. A warning is thrown when storage fields use the same storage slot key. The warning looks like this: ``` Two storage fields are using the same storage key. First field: storage::ns1.f3 Second field: storage::ns2.f4 Key: 5F4C20CE4BD128E5393A4C2B82007DAC795FA0006D01ACF8DB4C42632BC680CA ``` This PR does not include yet the necessary documentation updates. Created dev-rel documentation request: https://github.com/FuelLabs/devrel-requests/issues/14 ## Checklist - [ ] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: IGI-111 <igi-111@protonmail.com>	2024-06-18 16:03:39 +04:00
Daniel Frederico Lins Leite	be5e1344d1	Fix mod by zero constant folding (#6112) ... ## Description This PR fixes a problem with constant folding optimization pass with the mod operator. Unfortunately, we were not checking that the RHS was not zero. So expressions like `mod 1 0` were packing the compiler. ## 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. - [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.	2024-06-13 09:40:28 -07:00
Joshua Batty	4fe6f1ed51	Rename module terminology to program (#6056) ... ## Description Currently we have the ability to cache programs and also clear these programs from the engines using a garbage collector. The current terminology refers to modules rather than programs. I want to implement more granular caching and GC at the module level rather than just at the program level. This helps clear up what is actually being cached and cleared from the GC. ## Checklist - [ ] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers. Co-authored-by: IGI-111 <igi-111@protonmail.com>	2024-05-27 13:53:34 +00:00
IGI-111	2f0392ee35	Bump to v0.60.0 (#6049) ... Co-authored-by: João Matos <joao@tritao.eu>	2024-05-22 19:34:47 +02:00
Daniel Frederico Lins Leite	573a9ff757	fix dca for encoding v1 autogenerated code (#6006) ... ## Description This PR is part of https://github.com/FuelLabs/sway/issues/5727 and fixes a problem with AbiEncode/AbiDecode code generation. The problem lies in the fact that to encode/decode structs we need to "touch" all fields. Which makes all fields to pass DCA. Now, when a `StructFieldAccess` lives inside an autogenerated source, the "code flow graph" will be built as usual, but no edge will be created to the struct field, nor to the field owner struct declaration. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2024-05-20 16:31:55 +04:00
IGI-111	d9985d8111	Bump to v0.59.0 (#6030)	2024-05-17 11:29:22 +00:00
João Matos	221e18b8c7	Implement Display and DisplayWithEngines for some more types (#5999) ... ## Description This PR implements `Display` and `DisplayWithEngines` for some more types to help with debugging. ## Checklist - [ ] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2024-05-17 08:03:56 +00:00
Joshua Batty	8d50370814	change to use parking_lot::RwLock for better performance (#6014) ... ## Description Switching from `std::sync::RwLock` to `parking_lot::RwLock` is giving us a 10% further performance increase. before: `13.459551958s` after: `12.125325542s` ## 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.	2024-05-15 07:50:12 +00:00
Kaya Gökalp	9579dd2f77	chore: bump to v0.58.0 (#6003) ... ## Description Bumps sway repo to 0.58.0.	2024-05-13 16:44:55 -07:00