1324 commits

Author	SHA1	Message	Date
xunilrj	27289d1eea	fix locals offset	2025-08-04 14:11:13 -03:00
xunilrj	6ac40797aa	move optimization for ASM generation using local initializer	2025-08-01 16:37:20 -03:00
xunilrj	eab04bd053	fmt and clippy issues	2025-08-01 16:33:39 -03:00
xunilrj	409fc322eb	fmt and clippy issues	2025-08-01 16:33:39 -03:00
xunilrj	b855b2d986	use mcli when initializing array repeat	2025-08-01 16:33:39 -03:00
Vaivaswatha N	05e667dfc9	Remove some uses of ptr_to_int and int_to_ptr, using ptr instead (#7297) ... This is in preparation for the argument mutability analysis. This PR also has some skeleton code for this analysis, but the actual analysis is still a `todo!()`. The analysis will also have better precision if we use fewer asm blocks, but I'll get to that after working on the analysis itself.	2025-08-01 19:22:59 +10:00
Daniel Frederico Lins Leite	22d858682b	Fix const generics standalone fns (#7292) ... ## Description Continuation of https://github.com/FuelLabs/sway/issues/6860. ## 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-07-23 16:31:09 +04:00
Vaivaswatha N	a5e61488da	Represent RawUntypedPtr AST type using a new Pointer IR type (#7272) ... The existing `Pointer` IR type is renamed to `TypedPointer` (to be consistent with the existing `Slice` / `TypedSlice` IR types).	2025-07-22 04:26:38 +00:00
Daniel Frederico Lins Leite	d8536d384f	Clone implementation for string arrays (#7290) ... ## Description Continuation of https://github.com/FuelLabs/sway/issues/6860. `Clone` implementation for string arrays. ## 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-07-21 07:02:08 -03:00
Daniel Frederico Lins Leite	926cb4d098	Fix type check for variables in const generics (#7273) ... ## Description Fixes https://github.com/FuelLabs/sway/issues/7260. ## 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-07-20 08:29:34 +04:00
Daniel Frederico Lins Leite	0339852289	Better observability for the compiler (#7250) ... ## Description Whilst finishing "const generics" I spent a LOT of time trying to find why some cases where not working. Until I found the issue on a "indirect input" for the method `type_check_method_application`. The issue is that some other method was returning a wrong value, and although the solution is not hard, there is no way to fix just this problem, and there is no way to assert this returned value to guarantee that the problem will not return. To start to improve these kind of tests, and help debug problems, this PR start to create a "callback" mechanism that allows anyone using the compiler as a library, this will not be available at the CLI, to inspect and control logging. The integration in out e2e test harness is done by the `test.toml`. ``` category = "run" expected_result = { action = "return", value = 1 } expected_result_new_encoding = { action = "return_data", value = "0000000000000001" } validate_abi = true logs = """ if pkg != "std" && event == "on_before_method_resolution" && method == "len_xxx" { print_args(); trace(true); } if pkg != "std" && event == "on_after_method_resolution" && method == "len_xxx" { print_args(); trace(false); } """ ``` The `harness` framework will not call "logs" for every callback that happens outside of the "std" library. To allow interaction with the harness itself, some commands are available: - `print_args` print all the available arguments for that event on the "snapshot"; - `trace` enables/disables trace level logging, that also end up in the "snapshot". In the example above, we will generate the following snapshot: ``` --- source: test/src/e2e_vm_tests/harness_callback_handler.rs assertion_line: 14 --- on_before_method_resolution: FromModule { method_name: len_xxx }; Regular([]); S<unresolved T -> u64, N -> 3> before get_method_safe_to_unify: S<unresolved T -> u64, N -> 3> len_xxx<N -> None>(self: unresolved Self -> S<unresolved T -> T, N -> None>): u64 -> u64 after get_method_safe_to_unify: S<unresolved T -> u64, N -> 3>; len_xxx<N -> 3>(self: unresolved Self -> S<unresolved T -> u64, N -> None>): u64 -> u64 on_after_method_resolution: FromModule { method_name: len_xxx }; Regular([]); S<unresolved T -> u64, N -> 3>; len_xxx<N -> 3>(self: unresolved Self -> S<unresolved T -> u64, N -> None>): u64 -> u64; S<unresolved T -> u64, N -> 3> on_before_method_resolution: FromModule { method_name: len_xxx }; Regular([]); S<unresolved T -> u64, N -> 3> before get_method_safe_to_unify: S<unresolved T -> u64, N -> 3> len_xxx<N -> None>(self: unresolved Self -> S<unresolved T -> T, N -> None>): u64 -> u64 after get_method_safe_to_unify: S<unresolved T -> u64, N -> 3>; len_xxx<N -> 3>(self: unresolved Self -> S<unresolved T -> u64, N -> None>): u64 -> u64 ``` The important part is that the problem I want to fix it's there. On the line of "get_method_safe_to_unify", the "self" parameter const generic argument "N" is not being materialized, although the method resolution pass started with a fully materialized type. With this callback machinery it becomes easier to debug the problems, and possible to generate asserts to internal methods. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers.	2025-07-18 07:24:32 +00:00
Igor Rončević	e303b0f1ab	Add migration for new_hashing (#7287) ... ## Description This PR: - implements "Review existing usages of `StorageMap`, `sha256`, and `keccak256`" migration step for `new_hashing` experimental feature, as described in the Breaking Changes chapter of the tracking issue #7256. - extends the migration infrastructure by providing an optional help message related to an occurrance in code. Instead of returning only `Span`, migration steps now return an `Occurrance` that combine the `Span` with an optional help message. - extends the migration infrastructure to visit all the `TyExpressionVariant`s. For some of the expressions, the typed elements are still not provided. In such cases the migration step for `new_hashing` still detects an occurrence, but the help message lacks the detailed type information. - extends the migration infrastructure to visit all the declarations relevant for the `new_hashing` migration step. E.g.; `trait`, `abi`, and `storage` decls. Additionally, the PR implements `AsRawSlice` for `str`. Here is an excerpt of an output of the migration step run on a test project: ```console info: [new_hashing] Review existing usages of `StorageMap`, `sha256`, and `keccak256` --> /src/test.sw:62:39 | ... 12 | let _ = sha256("affected"); | ---------- info: This has type "str". ... 24 | let user_metadata_key_id = sha256((user_id, key)); | -------------- info: This has type "(b256, String)", that recursively contains "Bytes". | 71 | let _ = sha256_alias(StructCRec::new()); | ----------------- info: This has type "StructCRec", that recursively contains "Vec<u8>". | ::: /src/main.sw:52:5 | ... 13 | let _ = sha256(x); | - info: This has generic type "T". Review all the concrete types used with it. | 39 | directly_affected_str_array: StorageMap<str[3], u64> = StorageMap {}, | --------------------------- info: Review this storage field, because of "str[3]" in "StorageMap" key. | 43 | nested_affected_storage_maps: StorageMap<StructA, StorageMap<raw_slice, StorageMap<EnumARec, StorageVec<StorageMap<str[3], u64>>>>> = StorageMap {}, | ---------------------------- info: Review this storage field, because of "[u8; 0]", "slice", "[u8; 0]", and "str[3]" in "StorageMap" keys. | 52 | metadata: StorageMetadata = StorageMetadata {}, | -------- info: Review this storage field, because of potential custom storage type "StorageMetadata". 56 | 72 | storage.metadata.insert(sha256(handle_name), key, value); | ----------- info: This has type "String", that contains "Bytes". | | = help: New hashing changes the hashes of instances of the following types: = help: - string slices (`str`) = help: - string arrays (`str[N]`) = help: - arrays (`[T; N]`) = help: - raw slices (`raw_slice`) = help: - vectors (`std::vec::Vec<T>`) = help: - bytes (`std::bytes::Bytes`) = help: = help: To decide if opting-in to new hashing is backward-compatible and safe or not, = help: review if those types are directly used, or are contained in types: = help: - used as keys in `StorageMap`s, = help: - used in custom storage types, = help: - hashed using `sha256` or `keccak256` functions. = help: = help: ╔═════════════════════════════════════════════════════════════════════════════════════╗ = help: ║ The above occurrences must not be seen as comprehensive, but rather as a guideline. ║ = help: ║ Carefully review all the storage access and hashing patterns in your code. ║ = help: ║ E.g., using precomputed hashes, having custom `Hash` implementations, and similar. ║ = help: ╚═════════════════════════════════════════════════════════════════════════════════════╝ = help: = help: For a detailed migration guide see: https://github.com/FuelLabs/sway/issues/7256 ``` ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-07-18 04:40:36 +00:00
João Matos	f117e855ea	Add #[abi_name(name = "foo")] attribute to rename ABI items. (#7057) ... ## Description Add `#[abi_name(name = "foo")]` attribute to rename enum and struct ABI items. Here is example of how it can be used: ```sway contract; #[abi_name(name = "RenamedMyStruct")] struct MyStruct {} #[abi_name(name = "RenamedMyEnum")] enum MyEnum { A: () } abi MyAbi { fn my_struct() -> MyStruct; fn my_enum() -> MyEnum; } impl MyAbi for Contract { fn my_struct() -> MyStruct { MyStruct{} } fn my_enum() -> MyEnum { MyEnum::A } } ``` Closes https://github.com/FuelLabs/sway/issues/5955. ## Remarks The checking for ABI names is being done in the ABI generation phase, which made it a requirement to change the interface of ABI checking to return Results everywhere and passing Handler all the way down, so emitted errors can be passed down to the driver for reporting. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: IGI-111 <igi-111@protonmail.com>	2025-07-17 20:12:36 -07:00
Igor Rončević	6422650f37	Add backtrace build option (#7285) ... ## Description This PR adds the `backtrace` build option as described in the [ABI Backtracing RFC](https://github.com/FuelLabs/sway-rfcs/blob/ironcev/abi-backtracing/rfcs/0016-abi-backtracing.md). This is the second step in implementing #7276. Docs for `backtrace` build option will be added in a separate PR that will document the whole backtracking feature. ## 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) - [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-07-17 08:38:16 -07:00
Vaivaswatha N	a27d97984b	Partially revert #6795 (#7288) ... ## Description Fixes #7283	2025-07-17 11:43:26 -03:00
Hannes Karppila	74092cbbcd	Subroutine calls using the new JAL instruction (#7085) ... ## Description This PR contains an initial implementtion of subroutine calls using the in-progress [jump-and-link instruction `JAL`](https://github.com/FuelLabs/fuel-specs/pull/630). It substantially reduces the function call overhead: the old code used 4 instructions per call, while the new version uses 1-3 depending on the distance to the called function. ### Future optimizations * Reorder functions, so those that call each other are adjacent * Use absolute or IS-relative jumps where it makes sense, see https://github.com/FuelLabs/sway/issues/7267 ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-07-12 08:23:53 +00:00
Igor Rončević	8b7524666b	Add #[trace] attribute (#7277) ... ## Description This PR adds the `#[trace]` attribute as described in the [ABI Backtracing RFC](https://github.com/FuelLabs/sway-rfcs/blob/ironcev/abi-backtracing/rfcs/0016-abi-backtracing.md). This is the first step in implementing #7276. Docs for `#[trace]` attribute will be added in a separate PR that will document the whole backtracking feature. A check if an annotated function can actually panic will be added in a follow up PR that will implement the backtracing in the IR generation. ## 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-07-11 12:35:38 +00:00
Daniel Frederico Lins Leite	384f46f61d	Contract self impl (#7275) ... ## Description Continuation of https://github.com/FuelLabs/sway/pull/7030. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: hey-ewan <ewanretorokugbe@gmail.com> Co-authored-by: ewan ✦ <66304707+hey-ewan@users.noreply.github.com> Co-authored-by: IGI-111 <igi-111@protonmail.com>	2025-07-11 11:02:37 +00:00
Vaivaswatha N	0cae7a3195	treat string array values as if it were [u8; N] (#7258) ... The goal of this PR is to enable the check in the IR verifier to ensure that the operand to `ptr_to_int` instructions can only be pointers. The other changes are to support that.	2025-06-30 19:58:29 +05:30
Vaivaswatha N	586a968ef1	support __addr_of for all types (#7255)	2025-06-27 15:33:42 +12:00
IGI-111	5064247397	Stabilize ABI errors (#7241) ... ## Description Stabilize the `error_type` feature. Fixes #6765 ## 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: Igor Rončević <ironcev@hotmail.com>	2025-06-23 10:37:35 +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
João Matos	b202843150	Trait coherence fixes (#7211) ... ## Description This bundles up a couple fixes related to the trait coherence feature. [Remove LSP workaround for skipping trait coherence checks.](28b038d870) This has been fixed and is not necessary anymore since the underlying issue was fixed in 12eee9e0d2. [Use an hash set for calculating trait coherence unified trait types.](096b1c201a) This prevents some duplicated entries from being considered when building the initial unified map for trait coherence checks. [Prevent duplicated trait coherence checks for conflicting types.](95aadcd14e) This fixes https://github.com/FuelLabs/sway/issues/7187 and fixes coherence checking when multiple versions of the same library exist in the same package. [Improve trait coherence orphan rule error with expressive diagnostics.](c2dbff0696) ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2025-06-19 04:27:17 +00:00
Vaivaswatha N	e0724422c6	IR: Taking function arg address and representing references as pointers (#6967) ... ## Description This is the third PR to address #6351. It allows safely taking addresses of function arguments, and represents references (`&`) as pointers in the IR. Note: The entire function `type_correction` (in `ir_generation.rs`) and this [edit](2de7ab9ec1 (diff-3b0502f41aeb3c45ddbdb3cc590658d73d2bd7283671eb6d789d7e77a7dd2596R670)) in `compile.rs`, to handle return values, must be removed once we fix and finalize the syntax of references. Until then these two hacks need to stay. Ideally I wanted to put them both in one place (which is the `type_correction` pass), but the return type fix needs to happen, unfortunately, during IR gen. --------- Co-authored-by: IGI-111 <igi-111@protonmail.com> Co-authored-by: Igor Rončević <ironcev@hotmail.com>	2025-06-13 10:12:28 +10:00
João Matos	0e24afdc4f	Keep track of interface surface status for entries in trait map. (#7210) ... ## Description This adds bookkeeping information to the trait map so we can avoid emitting diagnostics for interface surface trait impls . What happens is that during type checking, we first check the interface surface as a first pass, and only then do a second pass for the whole implementation, and this causes some issues with emitting diagnostics that should not be emitted. ## 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-06-11 05:41:03 +00:00
Daniel Frederico Lins Leite	cee6f4e0e0	Const generics for "string array" and len methods (#7202) ... ## Description This PR is part of https://github.com/FuelLabs/sway/issues/6860. It implements "const generics" for "string arrays" and `len` methods for arrays and string arrays. ```sway #[cfg(experimental_const_generics = true)] impl<const N: u64> str[N] { pub fn len(self) -> u64 { N } } ```` ## 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: IGI-111 <igi-111@protonmail.com>	2025-06-02 20:20:09 +10:00
Daniel Frederico Lins Leite	b009621a8f	Removing needless allocations (clone, to_vec, collect etc...) (#7209) ... ## Description This PR remove needless memory allocation: 1 - it removes needless `.clone()`, `.to_vec()` and some `.collect()`; 2 - it wraps `TraitEntry` into a `SharedTraitEntry`. In a lot of cases, `TraitEntry` was being completely cloned, and only occasionally being mutated. Now its `clone()` is cheap, and the occasional needed complete `clone` has the inconvenience of requiring `fork_if_non_unique` to be called before mutation; 3 - `err_override` was cloning a lot of stuff and only used on errors. Now they are behind a closure that is normally not called; 4 - There were a lof of needless `Vec` when dealing with modules; 5 - `find_method_for_type` and others were generating a lot of temporary `Vec`. ## 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). - [ ] I have requested a review from the relevant team or maintainers.	2025-06-02 11:52:13 +04:00
Daniel Frederico Lins Leite	2d0021c20b	const-generics for enums (#7163) ... ## Description This PR is part of https://github.com/FuelLabs/sway/issues/6860 and allows `enums` to have "const generics" like the code below: ```sway enum E<T, const N: u64> { Nothing: (), Array: [T; N] } impl<T, const N: u64> E<T, N> { pub fn len_xxx2(self) -> u64 { N } } ``` ## 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>	2025-05-29 11:05:07 -03: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
Daniel Frederico Lins Leite	5e7e4bc82f	const generics for standalone fns (#7175) ... ## Description This PR is part of https://github.com/FuelLabs/sway/issues/6860 and allows standalone functions to have "const generics" like the code below: ```sway fn return_n<const NNN: u64>() -> u64 { NNN } ``` ## 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-05-23 10:08:24 +10:00
Joshua Batty	a4283762af	Refactor: Move SyncWorkspace from Session into ServerState (#7166) ... ## Description * Moves `SyncWorkspace` ownership from individual `Session` instances to a single, global instance within `ServerState`. * `SyncWorkspace` is now initialized once when the LSP server starts, creating a single temporary workspace clone. Also removes the `resync` function. This was causing the server and the IDE to fall out of sync with each other. For example, if you have 2 panels open and then save a file in one of the tabs but have unsaved changes in the other tab then those changes would not be reflected in the temp memory folder. This meant everything would be out of sync. We already are syncing everything on each keystroke per file so this fn was not necessary in the first place. This PR is a precursor to https://github.com/FuelLabs/sway/pull/7139 part of https://github.com/FuelLabs/sway/issues/7111 ## 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: zees-dev <63374656+zees-dev@users.noreply.github.com>	2025-05-19 14:13:42 +01:00
Hannes Karppila	39251b665b	Refactor jump label realization (#7088) ... ## Description Simplifies jump instruction generation, moving the actual instruction selection to a single location. Removes lots of error-prone duplicate logic around far jump rewriting. This theoretically has a slight size penalty in jump-heavy contracts, but in practice this should be neglible. For instance `mira-v1-core` isn't affected at all. This PR is makes it easier to implement further optimizations, especially those around the new JAL instruction and u16/u32 integer loading opcodes. In particular, data section packing should be a lot easier after this. ## 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: just a refactor, existing tests suffice - [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>	2025-05-14 12:39:29 +04:00
Igor Rončević	7386b19846	Remove double IR-compilation of contract methods (#7164) ... ## Description This PR removes the double compilation of contract methods in the IR, in the case of new encoding. The contract methods were first compiled as a part of the compilation of the `__entry` function, and afterwards, again separately. The contract methods compiled in the second compilation pass were later on removed as not reachable. The issue was brought to the surface in a test written by @hal3e in [fuel-rs PR that integrates ABI errors](https://github.com/FuelLabs/fuels-rs/pull/1651). In that particular test, because of the double compilation, a `panic` expression in a contract method got compiled twice and produced two same entries in the ABI JSON. Removing the double compilation resulted in a small reduction of bytecode size and gas usage. In some tests bytecode size got reduced for ~50 bytes and the gas usage for ~30 gas units. Additionally, the PR adjusts the printing of IR global variables, to be the same as printing of configurables and locals, without the spaces between individual entries. ## Checklist - [ ] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-05-12 16:52:58 +00:00
Sendi John	e7cd25a191	Rename AllocatedOpcode to AllocatedInstruction to follow fuel-spec/fuel-asm terminology (#7122) ... ## Description This commit renames `AllocatedOpcode` to `AllocatedInstruction` to align with the terminology used in the fuel-spec and fuel-asm crates, as introduced in the recent refactor (#4004). It also includes a review of other occurrences of the term "Opcode" to ensure consistency across the codebase. ## 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. --------- Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2025-05-06 08:26:09 +00:00
Hannes Karppila	1c885cf0f1	codegen optimization: symbolic fuel-vm interpretation (#7109) ... ## Description This PR adds an initial support to symbolic fuel-vm interpretation to improve codegen. The symbolic execution is designed to be extended in later PRs. In it's current form, it provides three distinct improvements: 1. If a temporary (allocated) register contains a value already held in another register, we can use that other register instead. This reduces register pressure, and removes unnecessary `mov` ops. 2. If a register already has the value we're setting it to, we can eliminate the instruction doing so. 3. For conditional jump instructions, if the value of the condition is known, one of the branches can be elminated. In such cases, the instruction is either removed or replaced with an unconditional jump. Dead code elimination pass can then potentially remove the now-unreachable branch. In addition to these changes, this PR takes the optimization level into account for asm generation. For debug builds, we only run the optimization passes once. But for release builds we run the optimization passes multiple times, until we either cannot eliminate any more operations, or until a fixed upper limit of rounds. For instance, this means that if the new pass added in this PR manages to eliminate a branch, and then dead code elimination removes that code, it could allow the interpretation pass to do even more work. To account for new optimization passes, I also organized them to mulple files, so that the ones which create private types are scoped well and thus easier to read. ## Impact project | size before | size after | size reduction -|-|-|- mira-v1-core | 89.384 KB | 83.480 KB | 6.6% ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). No changes required! - [x] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. Just updated pre-existing ones! - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: Vaivaswatha N <vaivaswatha.nagaraj@fuel.sh> Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2025-05-05 10:50:08 +03:00
Daniel Frederico Lins Leite	324f04fbab	Better Debug tests and impls for primitives and std lib types (#7119) ... ## Description This PR is a continuation of https://github.com/FuelLabs/sway/pull/7015. It is fixing the number printing function, which was not working correctly for zero. It also fixes a problem when printing `enum` variants. To improve `__dbg`, we are also now printing the argument span. An improved test now tests if all relevant `strucs` and `enums` from the `std` library are debug and show how they are printed. ## 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: kaya <kaya.gokalp@fuel.sh>	2025-05-02 06:40:34 -03:00
Igor Rončević	40cffb2975	Parse raw identifiers (r#<identifier>) in expressions (#7137)	2025-05-01 10:59:53 +01:00
Daniel Frederico Lins Leite	42321ef0e0	improve dbg intrinsic with fflush (#7126) ... ## Description This PR brings a new syscall "fflush" to help `EcalHandler` know when the `__dbg` is finished and they flush their buffers. In theory, Linux `fflush` is not a syscall because it just flushes "user-space" buffers. As we do not have this difference, we are still going to call `fflush` as a syscall. ## 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: João Matos <joao@tritao.eu>	2025-04-30 11:31:32 -03:00
Igor Rončević	5f64b96f9c	Implement panic expression (#7073) ... ## Description This PR introduces the `panic` expression to the language, as defined in the [ABI Errors RFC](https://github.com/FuelLabs/sway-rfcs/blob/master/rfcs/0014-abi-errors.md#panic). The `panic` expression can be used without arguments, or accept an argument that implements the `std::marker::Error` trait. The `Error` trait is implemented by the compiler for the unit `()`, string slices, and `#[error_type]` enums. Using the `panic` expression without arguments gives the symetry with the `return` expression and acts in the same way as having unit as an argument. ``` panic; panic (); panic "This is some error."; panic Errors::SomeError(42); ``` Panicking without an argument or with unit as argument is discouraged to use. In the upcoming PR that finalizes the ABI errors feature, we will emit a warning if the `panic` is used without arguments or with unit as argument. `panic` expression is available in all program kinds. In predicates it currently compiles only to revert. Once `__dbg` intrinsic is implemented, we can consider compiling to it in predicates. In the upcoming PR, the `error_codes` entry in the ABI JSON will be available for all program kinds. The dead code analysis for the `panic` expression is implemented in the straightforward way, following the current approach of connecting reverts to the exit node. This will be revisted in a separate PR, together with the open TODOs in the DCA implementation of `Return`. Essentially, we want reverting/panicking to connect to program exit and implicit returns to the exit node. Additionally, the PR: - extends `forc test` CLI attributes with `--revert-codes` that prints revert codes even if tests are successful but revert. - updates outdated "Logs Inside Tests" chapter in the documentation on unit testing. - extends the snapshot testing infrastructure to support `forc test` in snapshot tests. - fixes #7072. Partially addresses #6765. ## Breaking Change `panic` is a new reserved keyword. Once the `error_type` feature becomes integrated, compiling any existing code containing a "panic" as an identifier will result in an "Identifiers cannot be a reserved keyword." error. In this PR, `panic` keyword is hidden behind the `error_type` feature flag. This prevents existing code from breaking, unless opted-in. Note that, although being behind a feature flag, `panic` cannot be used in conditional compilation, means in combination with the `#[cfg(experimental_error_type = true/false)]`. The reason is that `cfg` evaluation happens after parsing, and we can either parse `panic` as a keyword or identifier during the parsing, because we cannot distinguish ambiguous cases like `panic;` or just `panic`. This limitation means, that introducing `panic` to `std` can be done only once the `error_type` feature is fully integrated. In practice, this is not a serious limitation, because introducing `panic` in `std` would anyhow, due to effort and design decisions, happen after the feature is integrated. We will provide a migration for this breaking change that will migrate the existing "panic" identifiers to "r#panic". ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-04-30 20:07:05 +10:00
João Matos	d2589216c2	Rework and fix associated const visibility for impl items (#6785) ... ## Description Fixes https://github.com/FuelLabs/sway/issues/6772. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-04-30 03:01:48 +00:00
Daniel Frederico Lins Leite	26e2ef875c	Support for const generics in structs (#7076) ... ## Description Part of https://github.com/FuelLabs/sway/issues/6860. This PR enables code like below to be written now. This will allow the implementation of `iter()` for arrays. ```sway struct S<T, const N: u64> {} impl<T, const N: u64> S<T, N> { pub fn len_xxx(self) -> u64 { N } } ``` Limited to `structs` now. `enum` will be implemented in a future 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. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: IGI-111 <igi-111@protonmail.com>	2025-04-29 19:16:48 -03: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
Igor Rončević	76268dcff7	Add support for experimental features in the parsing phase (#7124) ... ## Description This PR brings support for experimental features to the parsing phase. This is needed so that we can support use cases like, e.g., adding new language keywords behind a feature flag. A concrete example would be the `panic` keyword added in #7073. The parsing of the `panic` token differs if it is interpreted as a keyword (when the `error_type` experimental feature is active) or as a regular identifier (when `error_type` is off). Because `ExperimentalFeatures` are needed in the `Parse::parse(parser: &mut Parser)` methods, the `Parser` got extended with the `experimental` field. The consequence of bringing the `ExperimentalFeatures` to the parsing phase is, that `swayfmt` and `forc fmt` can also require an experimental feature to be set, to properly parse a project. In those tools, `ExperimentalFeatures` are passed as a field on the `Formatter`. Note that this PR does not put the provided experimental flags into use. The first concrete usage will be in #7073. This PR is a prerequisite for #7073. ## 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-04-29 11:36:37 +12: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
João Matos	3afc5c18c8	Improved trait coherence checking (#6844) ... ## Description This PR refines trait coherence checking to guarantee that there is only one valid implementation for each trait. It introduces improved orphan rules and more rigorous overlap checks to prevent conflicting trait implementations. With these changes, the system now more reliably enforces coherence, ensuring that traits are implemented uniquely, and reducing potential ambiguities. This approach mirrors Rust’s design by enforcing two distinct safety and coherence checks on trait implementations: **1. Orphan Rules Check** The orphan rules require that for any trait implementation, either the trait or the type must be defined within the current package. This restriction prevents external packages from implementing foreign traits for foreign types, which could otherwise lead to conflicting implementations and ambiguities across different parts of a codebase. Essentially, it helps maintain clear ownership and boundaries of trait implementations. **2. Overlap Impl Check** The overlap impl check ensures that no two trait implementations can apply to the same type in an ambiguous manner. If two implementations could potentially match the same type, it would be unclear which one should be used, leading to coherence issues. By enforcing that implementations do not overlap, the system guarantees that trait resolution is unambiguous and predictable. Together, these checks promote a robust and maintainable system by ensuring that trait implementations are both locally controlled (orphan rules) and non-conflicting (overlap check). The test suite has been updated to comply with the new rules. However, there is one current limitation regarding arrays. For arrays, the coherence checks have been relaxed to avoid the need for numerous concrete implementations in the standard library for traits like `Eq` and `PartialEq`. This decision was made because support for const generics is expected soon, which will allow these traits to be implemented more cleanly. Closes issue https://github.com/FuelLabs/sway/issues/5892. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-04-17 22:57:45 +01:00
Daniel Frederico Lins Leite	2b06d79568	Sway compiler optimizations (#7080) ... ## Description This PR is a prequel to https://github.com/FuelLabs/sway/pull/7015. `Debug` trait auto-implementation is causing some performance issues. So this PR will try to compensate by doing the following optimizations: 1 - `filter_dummy_methods` is cloning `TyFunctionDecl` needlessly. Another small optimization is that instead of calling `ConcurrentSlab::get(...)` and cloning and dropping an `Arc`. There is a new `ConcurrentSlab::map(...)` method that avoids all that. 2 - A lot of time was being spent on `node_dependencies`. One the primary wastes was hashing nodes multiple times. To avoid that, each node will "memoize" its own hash, and a `Hasher` that does nothing is being used. This means that each node's hash will only be calculated once. 3 - The third optimization is a little bit more polemic. It involved the fact that we clone `TyFunctionDecl` a LOT. And some fields are more expensive than others, for example, `body`, `parameters` and `constraints`. To alleviate these excessive clonings, these fields are now behind an `Arc` (because LSP need them to be thread safe), and there is a "COW` mechanism specifically for them when they need mutation. ## Detailed analysis The first step is to compile `forc` and run Valgrind. My analysis was done using the debug build; values may vary on the release build, of course. ``` cd test/src/e2e_vm_tests/test_programs/should_pass/language/intrinsics/transmute cargo r -p for valgrind --tool=callgrind --dump-instr=yes --simulate-cache=yes --collect-jumps=yes /home/xunilrj/github/sway/target/debug/forc build ``` The first that caught my attention was a function called `filter_dummy_methods` that is called around 150k times. Inside of it, there is a useless call to `TyFunctinDecl::clone()`. If Valgrind is correct, this `clone` is spending 10% of the compilation. This explains the first optimization.  Another 20% of the time is spent inside `order_ast_nodes_by_dependency`.  Inside this function, there is a function called `recursively_depends_on` that corresponds to 10% of the compilation, and more than half of it is spent hashing nodes. This explains the second optimization.  Another source of waste is the amount of `TyFunctionDecl::clone` that we call. It amounts to 12% of the compilation time. The problem is that it is much harder to remove/optimize these clones. I assume that a lot of these clones are not needed. One of the reasons is the way `SubtsType` and other monomorphization mechanisms were built; we first need to clone something, and then we try to mutate the cloned version. I don´t have a number, but I imagine in a lot of cases, the cloning and the mutation were not needed. **Maybe someone can come up with a test to see if we can avoid cloning/mutation. I bet that this will increase performance tremendously.**  But what I did was I chose all the fields that are costly to be cloned: `body`, `parameters`, `call_path`, `type_parameters`, `return_type`, and `where_clause`; and I put them behind an `Arc`. If my assumption is correct, making them cheap to be cloned will improve performance because we will just clone their `Arc`, and never mutate them. Unfortunately, there is no easy way to avoid cloning in some cases. For example, when monomorphizing, our algorithms don´t know "from the outside" that a `body` will never change, and we trigger the COW mechanism and end up cloning the item inside the `Arc`, even when we don´t need it.  ## 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) - [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: IGI-111 <igi-111@protonmail.com>	2025-04-14 23:20:43 -07:00
João Matos	12eee9e0d2	Cache and restore namespace module for cached modules (#7078) ... This extends the existing module caching support to also cache and restore namespace modules. This is necessary for correct LSP functionality with the new trait coherence feature. ## Checklist - [ ] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers. Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2025-04-14 01:41:09 +00:00
Igor Rončević	2501c76008	Fix compiler panic on configurable initialization (#7068) ... ## Description This PR fixes the compiler panic in the case of a configurable initializer that couldn't be const evaluated, like e.g: ```sway fn non_const_evaluable() -> u64 { asm() { fp: u64 } } configurable { CONFIG: u64 = non_const_evaluable(), } ``` Instead of a panic: ``` thread 'main' panicked at sway-core/src/ir_generation/compile.rs:320:14: called `Result::unwrap()` on an `Err` value: NonConstantDeclValue { span: Span { src (ptr): 0x564e0b311600, source_id: Some(SourceId(6291595)), start: 1009, end: 1019, as_str(): "CONFIG" } } ``` the compiler now emits an error: ``` CONFIG: u64 = non_const_evaluable(), ^^^^^^ Could not evaluate initializer to a const declaration. ``` ## Checklist - [ ] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-04-07 10:07:46 +00:00
Igor Rončević	c25c5af2da	Add #[error_type] and #[error] attributes (#7058) ... ## Description This PR adds `#[error_type]` and `#[error]` attributes to the collection of known attributes, as defined in the [ABI Errors RFC](https://github.com/FuelLabs/sway-rfcs/blob/master/rfcs/0014-abi-errors.md). Additionally, the PR updates the outdated documentation for _Attributes_ and _Keywords_. Partially addresses #6765. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-04-07 09:37:04 +00:00