1360 commits

Author	SHA1	Message	Date
xunilrj	27289d1eea	fix locals offset	2025-08-04 14:11:13 -03:00
xunilrj	54f3d20200	update test	2025-08-04 13:36:42 -03:00
xunilrj	363ec6f155	udpdate tests	2025-08-01 16:54:21 -03:00
xunilrj	1bf5300691	udpdate tests	2025-08-01 16:42:12 -03:00
xunilrj	700b85fd3a	update tests	2025-08-01 16:38:02 -03:00
xunilrj	6ac40797aa	move optimization for ASM generation using local initializer	2025-08-01 16:37:20 -03:00
xunilrj	ab8ec4de7f	update tests	2025-08-01 16:37:20 -03:00
xunilrj	3494eda35a	update tests	2025-08-01 16:37:18 -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
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	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
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
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
Igor Rončević	8d4178f12d	Implement new hashing (#7259) ... ## Description This PR implements new hashing, as explained in the tracking issue #7256. New hashing is an opt-in experimental feature with the feature flag `new_hashing`. The new hashing hashes lengths as prefix to the content hash for the following built-in and `std` types: - string slices (`str`) - arrays (`[T; N]`) - `std::vec::Vec<T>` - `std::bytes::Bytes` Some of the `std` types that use the above types internally for storing their content still hash only the content, without the length prefix of the container. The reason for this is that 1) the choice of the container is just an implementation detail and 2) the semantics of the type requires only the content (mostly of the fixed, type-specific length) to be hashed. A typical example would be `std::b512::B512` where, same to `b256` we want to hash only the content. Notice that this does not cause the security issue described in #7256. Here is the complete list of those types: - `std::crypto::secp256k1::Secp256k1` - `std::crypto::secp256r1::Secp256r1` - `std::crypto::message::Message` - `std::crypto::public_key::PublicKey` - `std::b512::B512` Some of the implementations differ based on the combination of `const_generics` and `new_hashing` features. Therefore, on CI, we have a step testing both experimental features together. Additionally, the PR: - adds missing `Hash` implementations for string arrays (`str[N]`). - adds testing of `const_generics` experimental feature to CI. ## 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-07-11 14:39:29 +12: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
Vaivaswatha N	776c6cf474	minor adjustment to inliner heuristic (#7232) ... This change reduces the generated code size on our `should_pass` testsuite. Numbers are attached. [should_pass_master.txt](https://github.com/user-attachments/files/20754502/should_pass_master.txt) [should_pass_inliner.txt](https://github.com/user-attachments/files/20754501/should_pass_inliner.txt) --------- Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2025-06-23 06:17:05 +05:30
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
Igor Rončević	f12c789b57	Optimize existing and add missing Hash implementations (#7238) ... ## Description This PR: - optimizes the existing `std:#️⃣:Hash` implementations in the `std`, for bytecode size and gas usage. The optimizations are based on eliminations of intensive memory allocations and memory copying. On a sample application, the **bytcode size reduction was ~10%**, and the **gas usage reduction >50%**. The detailed results are presented below. - fixes #7234 - adds `Hash` implementations for: - unit type `()`, - tuples of a single element `(T, )`, - empty arrays `[T; 0]`, - other `std` types that were missing `Hash` implementations, like, e.g.: `Duration`, `Time`, `U128`, `B512`, etc. Note that `Hash` implementations were not provided for various Error enums. ## Performance Optimizations To measure performance gains, a sample application was used, that: - hashed all built-in types individually, as well as tuples and array of those, and `Bytes` and `Vec`. - hashed all the above types within a same `Hasher`, simulating hashing of complex types like, e.g., structs. The bytcode size of the sample application got **reduced from 9560 to 8584 bytes (10.21% reduction)**. The overall gas usage for hashing types individually **got reduced from 35826 to 15562 (56.56% reduction)**. The overall gas usage for hashing types within a same `Hasher` **got reduced from 34951 to 14443 (58.67% reduction)**. The `in_language` tests for hashing, `hash_inline_tests`, also demonstrated a **significant reduction in gas usage, up to 57.82%**. A small regression is noticable when hashing empty types, e.g., unit. We expect that regression also to disappear once `const fn` is implemented, and local constants could be evaluated from generic functions. <details> <summary>Expand to see the detailed gas cost comparison for all `hash_inline_tests`</summary> | Test | Before | After | Percentage | |------|--------|-------|------------| | hash_address | 10070 | 6366 | 36.78% | | hash_array_10 | 33691 | 15867 | 52.90% | | hash_array_1 | 4870 | 3102 | 36.30% | | hash_array_2 | 8069 | 4517 | 44.02% | | hash_array_3 | 11219 | 5883 | 47.56% | | hash_array_4 | 14369 | 7249 | 49.55% | | hash_array_5 | 17519 | 8615 | 50.82% | | hash_array_6 | 20917 | 10229 | 51.10% | | hash_array_7 | 24109 | 11637 | 51.73% | | hash_array_8 | 27302 | 13046 | 52.22% | | hash_array_9 | 30494 | 14454 | 52.60% | | hash_array_empty | 773 | 777 | -0.52% | | hash_asset_id | 10070 | 6366 | 36.78% | | hash_b256 | 9604 | 5900 | 38.57% | | hash_b512 | 6028 | 4476 | 25.75% | | hash_bool | 3885 | 1993 | 48.70% | | hash_bytes | 8200 | 7112 | 13.27% | | hash_call_params | 11439 | 6019 | 47.38% | | hash_contract_id | 10070 | 6366 | 36.78% | | hash_duration | 4753 | 2985 | 37.20% | | hash_ed25519 | 18268 | 14780 | 19.09% | | hash_evm_address | 10098 | 6394 | 36.68% | | hash_fn_sha256_str_array | 1953 | 1167 | 40.25% | | hash_hasher_write_str | 2512 | 2013 | 19.86% | | hash_hasher_write_str_array | 2306 | 1807 | 21.64% | | hash_identity | 30526 | 14998 | 50.87% | | hash_input | 11766 | 5718 | 51.40% | | hash_message | 3003 | 3099 | -3.20% | | hash_option | 21373 | 9511 | 55.50% | | hash_output | 19649 | 9569 | 51.30% | | hash_point2d | 6861 | 4801 | 30.02% | | hash_public_key | 7372 | 7692 | -4.34% | | hash_result | 27083 | 11423 | 57.82% | | hash_scalar | 4159 | 3313 | 20.34% | | hash_secp256k1 | 18268 | 14780 | 19.09% | | hash_secp256r1 | 18268 | 14780 | 19.09% | | hash_signature | 31213 | 16936 | 45.74% | | hash_str | 6902 | 5417 | 21.52% | | hash_string | 5453 | 5252 | 3.69% | | hash_time | 4753 | 2985 | 37.20% | | hash_transaction | 23604 | 11508 | 51.25% | | hash_tuple_1 | 4834 | 3066 | 36.57% | | hash_tuple_2 | 7997 | 4445 | 44.42% | | hash_tuple_3 | 11147 | 5811 | 47.87% | | hash_tuple_4 | 14297 | 7177 | 49.80% | | hash_tuple_5 | 17447 | 8543 | 51.03% | | hash_u128 | 7943 | 4391 | 44.72% | | hash_u16 | 9384 | 5860 | 37.55% | | hash_u256 | 9600 | 5896 | 38.58% | | hash_u32 | 9384 | 5860 | 37.55% | | hash_u64 | 9372 | 5836 | 37.73% | | hash_u8 | 7740 | 3704 | 52.14% | | hash_unit | 771 | 775 | -0.52% | | hash_vec | 53077 | 33733 | 36.45% | </details> ## Breaking Changes Strictly seen, adding `Hash` implementations for `std` types like `Option<T>` represents a breaking change for those who eventually had their own implementations. However, if such implementations existed, after introducing strict trait coherence checks, they already became invalid, because neither the `Hash` trait nor the types `Hash` is implemented for are part of third party packages, but contained within the `std`. Thus, we can have a breaking change only if someone migrates from an older version that does not have trait coherence in place. But in that case, the trait coherence itself will already report breaking change errors. Because `Hash` implementations for `std` types must and should have already been provided within the `std`, we can treat adding those implementations as a bug fix. ## 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-06-18 10:47:50 -07:00
Cameron Carstens	52bd44d510	Add verified assets to AssetId implementation (#7225) ... ## Description This PR adds the verified assets to the `AssetId` implementation. This enables developers to quickly access assets that have been verified by the Fuel team and enables additional safety by ensuring the correct `AssetId` is being used. Additionally, it further integrates Sway into the Fuel ecosystem enhancing the developer experience. We may want to consider doing the same for verified contracts https://docs.fuel.network/docs/verified-addresses/contracts/ ## 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-06-17 10:01:03 +02: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
Igor Rončević	14dc752754	Respect CLI flags in unit_test_pass E2E tests (#7226) ... ## Description This PR passes the CLI flags `--release`, `--print...`, and `--target` to the compilation of the tests in the `unit_test_pass` category. Passing the `--release` flag is especially important, because up to now, `unit_test_pass` tests were always building the debug version of binaries, even when the test suite was executed as `--release`. ## 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-06-10 13:33:10 +04:00
Igor Rončević	134916d5b4	Support ABI errors in forc test (#7224) ... ## Description This PR adds support for ABI errors in `forc test`. If a unit test reverts, the received revert code is inspected for known error signals (e.g., coming from `assert`, or `require`) and for ABI errors. Analysis of the received revert code is encapsulated within the `forc_util::tx_utils::RevertInfo` struct implementation. This way, it can be reused between the `forc test` and `forc call`. However, on the long term, this abstraction should be moved to `fuel-abi-types`, because its whole logic is ABI related, and it should also be shareable with the Rust SDK. The reason for temporary placing it within `forc-util` crate is to get the support for ABI errors in `forc test` in the next Sway release, without the need for a new `fuel-abi-types` release that triggers the circular dependency between Sway and Rust SDK repositories. Additionally, the PR unifies the display of test outputs - logs, debug output, and reverts: - for passing tests, none of the output is shown by default, unless specified on the CLI. - for failing tests, all the output is displayed in the "failures" section. - because the `__dbg` output is not a log, a dedicated `--dbgs` CLI argument is added, for all ecal outputs. - because the output of a revert now shows all available information and not only the revert code, the `--revert-codes` CLI argument is renamed to `--reverts`. Closes #7089. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-06-10 06:57:07 +04:00
Cameron Carstens	fe8a3ef37a	Support GM_GET_CHAIN_ID GM opcode with chain_id() function (#7222) ... ## Description Adds a `chain_id()` function to return the current chain id using the `GM_GET_CHAIN_ID` opcode. ## 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-06-05 15:51:16 +00:00
IGI-111	58bf38ef9c	Bump to 0.68.7 (#7219)	2025-06-04 09:11:55 -03:00
kaya	6c30edbbe3	feat: implicitly depend on std from registry, not via git (#7204) ... ## Description closes #7040. With this PR we are marking the registry support *completed* we now have std deployed to forc.pub and forc using that std implicitly if no tag, branch, or specific git tag is supplied in env variables (this is needed by downstream, such ash the sdk for their CI etc, so we are keeping the old behavour for their dev flow).	2025-06-04 18:11:45 +12:00
Igor Rončević	0ac6294530	Implement Hash for Vec<T> (#7217) ... ## Description This PR implements `Hash` for `Vec<T>` where `T` is `Hash`. We need this implementation in the `std`, otherwise none of the other packages will be able to provide a `Hash` implementation for `Vec<Something>` because of the orphan rule violation (see: #7216). Closes: - #7216 ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-06-03 13:05:54 +04: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
Cameron Carstens	d6804729c9	Introduce the Time Library (#7206) ... ## Description This PR introduces a comprehensive UNIX time handling library to the Sway standard library, providing essential time manipulation capabilities for smart contracts. Time operations are fundamental for many smart contract use cases: - Token vesting schedules - Auction deadlines - Time-locked transactions - Subscription renewals - Staking periods Currently, Sway lacks standardized time utilities, forcing developers to: - Handle time conversions manually - Implement custom time logic in every contract - Risk errors in critical time calculations This library solves these problems with a robust, well-tested time abstraction. ### Duration Handling ```sway // Create durations using natural units let lock_period = Duration::days(90); let auction_extension = Duration::minutes(15); // Convert between units log(lock_period.as_weeks()); // ≈12.857 weeks log(auction_extension.as_seconds()); // 900 seconds // Duration arithmetic let total_lock = lock_period + Duration::weeks(2); ``` ### Blockchain Time Operations ```sway // Get current block time let now = Time::now(); // Create future/past timestamps let unlock_time = now.add(Duration::days(30)); let vesting_start = now.subtract(Duration::weeks(12)); // Measure time differences let time_elapsed = now.duration_since(vesting_start).unwrap(); ``` ### TAI64 ↔ UNIX Conversion Support for the existing TAI64 `timestamp()` functionality is maintained. ```sway // Native TAI64 from blockchain let tai_timestamp = timestamp(); // Convert to UNIX time let unix_time = Time::from_tai64(tai_timestamp); // Convert back to TAI64 let converted_tai = unix_time.as_tai64(); assert(tai_timestamp == converted_tai); ``` ### Benefits - Safety: Prevents common time calculation errors - Accuracy: Properly handles TAI64/UNIX conversion - Productivity: Reduces boilerplate for time operations - Consistency: Standardized approach across contracts - Readability: Natural time unit expressions ### Future Extensions Once support between different types for `Add`, `Subtract`, `Multiply`, etc are implemented, we may be able to do the following: ```sway let now = Time::now(); let future = now + Duration::DAY; let three_weeks = Duration::WEEK * 3; ``` Closes https://github.com/FuelLabs/sway/issues/3945 ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-05-30 19:03:23 +10:00
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
Igor Rončević	68e0423e15	Run forc-unit-tests on CI in release and debug mode (#7159) ... ## Description This PR: - changes the configuration of Forc and Forc plugins used in CI steps from `debug` to `release`. - changes the `forc-unit-tests` CI step, to run the tests both in `debug` and `release` mode. By switching to `release` builds, we ensure that we test the versions that are actually released, unlike the `debug` version. As a consequence, execution time of CI steps gets shortened. The drawback is potentially not catching issues detectable only in the `debug` mode, like, e.g., overflows. We will add a separate CI workflow, running nightly or on tagged versions only, that will use `debug` builds as explained in #7168. Currently, we are running `forc-unit-tests` only in the `debug` mode. Compiler panics in `in_language_tests`, described in #7157, that happens only in `release` mode, shows that it is beneficial to run the unit test both in `debug` and `release` mode. Similar is with compiler panics described in #7161. The PR also removes the explicit `forc build` part from those tests and leaves only the `forc test` part. The reasoning behind that change is, that `forc test` also builds the projects, indeed with tests included, but, since we currently don't support `#[cfg(test)]`, otherwise unchanged. Running `forc build` in addition effectively doubles the test execution time, and the actual benefit in testing, compared to running only `forc test` is, in best case, negligible. ## 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: Sophie Dankel <47993817+sdankel@users.noreply.github.com>	2025-05-13 14:08:53 +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
Igor Rončević	bd3813606a	Optimize vec and bytes modules for bytecode size and gas usage (#7162) ... ## Description This PR mostly optimizes implementations of several traits, like `AbiEncode`, `Iterator`, `PartialEq`, and methods for `Vec` and `Bytes`. One typical common optimization was replacing the internal calls to the public `get` method with a direct element read. Each call to the public `get` in internal implementations of those traits had an overhead of double-checking the boundary and unnecessary wrapping and unwrapping the fetched value. Also, whenever possible `mcp` instruction was used for converting between `Bytes` and `Vec<u8>`, instead of costly iteration and copying of each element individually. The PR also removes calls to getters in internal implementations to mitigate the issue of inlining of getters explained in #7152. The bytecode size of the sample script that uses optimized code was **reduced for 37.58%, from 2384 bytes to 1488**: ``` script; use std::bytes::Bytes; fn main() { let vec: Vec<u8> = Vec::new(); let bytes: Bytes = vec.into(); let vec: Vec<u8> = bytes.into(); let _ = vec == vec; for _ in vec.iter() { } let _ = bytes == bytes; for _ in bytes.iter() { } } ``` Out of 822 `in_language_tests`, **303 tests got reduced gas costs, up to 57.75% and in average 18.97%**. <details> <summary>Click to see improvements in gas costs</summary> | Test | Before | After | Percentage | |------|--------|-------|------------| | address_inline_tests::address_hash | 1648 | 1468 | 10.92% | | address_inline_tests::address_try_from_bytes | 1968 | 1714 | 12.91% | | address_inline_tests::address_try_into_bytes | 11555 | 9566 | 17.21% | | asset_id_inline_tests::asset_id_hasher | 1240 | 1105 | 10.89% | | asset_id_inline_tests::asset_id_try_from_bytes | 1968 | 1714 | 12.91% | | asset_id_inline_tests::asset_id_try_into_bytes | 11555 | 9566 | 17.21% | | b512_inline_tests::b512_into_bytes | 22732 | 18823 | 17.20% | | b512_inline_tests::b512_try_from_bytes | 2372 | 2127 | 10.33% | | bytes_conversions_b256_inline_tests::b256_from_be_bytes | 4401 | 3069 | 30.27% | | bytes_conversions_b256_inline_tests::b256_from_le_bytes | 5681 | 3810 | 32.93% | | bytes_conversions_b256_inline_tests::b256_to_be_bytes | 5337 | 4697 | 11.99% | | bytes_conversions_b256_inline_tests::b256_to_le_bytes | 6951 | 5879 | 15.42% | | bytes_conversions_u16_inline_tests::u16_from_be_bytes | 285 | 218 | 23.51% | | bytes_conversions_u16_inline_tests::u16_from_le_bytes | 285 | 218 | 23.51% | | bytes_conversions_u16_inline_tests::u16_to_be_bytes | 365 | 325 | 10.96% | | bytes_conversions_u16_inline_tests::u16_to_le_bytes | 366 | 326 | 10.93% | | bytes_conversions_u256_inline_tests::u256_from_be_bytes | 4413 | 3081 | 30.18% | | bytes_conversions_u256_inline_tests::u256_from_le_bytes | 5681 | 3810 | 32.93% | | bytes_conversions_u256_inline_tests::u256_to_be_bytes | 5376 | 4736 | 11.90% | | bytes_conversions_u256_inline_tests::u256_to_le_bytes | 6951 | 5879 | 15.42% | | bytes_conversions_u32_inline_tests::u32_from_be_bytes | 435 | 325 | 25.29% | | bytes_conversions_u32_inline_tests::u32_from_le_bytes | 435 | 325 | 25.29% | | bytes_conversions_u32_inline_tests::u32_to_be_bytes | 594 | 514 | 13.47% | | bytes_conversions_u32_inline_tests::u32_to_le_bytes | 594 | 514 | 13.47% | | bytes_conversions_u64_inline_tests::u64_from_be_bytes | 713 | 518 | 27.35% | | bytes_conversions_u64_inline_tests::u64_from_le_bytes | 713 | 518 | 27.35% | | bytes_conversions_u64_inline_tests::u64_to_be_bytes | 1052 | 892 | 15.21% | | bytes_conversions_u64_inline_tests::u64_to_le_bytes | 1052 | 892 | 15.21% | | bytes_inline_tests::bytes_append | 3619 | 2900 | 19.87% | | bytes_inline_tests::bytes_append_empty | 1243 | 990 | 20.35% | | bytes_inline_tests::bytes_append_empty_self | 151 | 130 | 13.91% | | bytes_inline_tests::bytes_append_self | 2117 | 1667 | 21.26% | | bytes_inline_tests::bytes_append_to_empty | 1662 | 1349 | 18.83% | | bytes_inline_tests::bytes_as_raw_slice | 716 | 572 | 20.11% | | bytes_inline_tests::bytes_b256_into | 2880 | 1536 | 46.67% | | bytes_inline_tests::bytes_b256_try_from | 6684 | 3812 | 42.97% | | bytes_inline_tests::bytes_bigger_than_3064 | 249483 | 120753 | 51.60% | | bytes_inline_tests::bytes_buffer_ownership | 1335 | 1321 | 1.05% | | bytes_inline_tests::bytes_capacity | 1010 | 662 | 34.46% | | bytes_inline_tests::bytes_clear | 691 | 542 | 21.56% | | bytes_inline_tests::bytes_clear_empty_bytes | 273 | 227 | 16.85% | | bytes_inline_tests::bytes_clear_twice | 926 | 712 | 23.11% | | bytes_inline_tests::bytes_clone | 1654 | 1237 | 25.21% | | bytes_inline_tests::bytes_eq | 1261 | 925 | 26.65% | | bytes_inline_tests::bytes_for_loop | 2110 | 1393 | 33.98% | | bytes_inline_tests::bytes_from_b256 | 2875 | 1531 | 46.75% | | bytes_inline_tests::bytes_from_raw_slice | 332 | 309 | 6.93% | | bytes_inline_tests::bytes_from_vec_u8 | 2135 | 1092 | 48.85% | | bytes_inline_tests::bytes_get | 1476 | 1221 | 17.28% | | bytes_inline_tests::bytes_insert | 1332 | 1037 | 22.15% | | bytes_inline_tests::bytes_insert_back | 1341 | 1046 | 22.00% | | bytes_inline_tests::bytes_insert_before_back | 1348 | 1053 | 21.88% | | bytes_inline_tests::bytes_insert_front | 1339 | 1044 | 22.03% | | bytes_inline_tests::bytes_insert_twice | 2242 | 1781 | 20.56% | | bytes_inline_tests::bytes_into_raw_slice | 716 | 572 | 20.11% | | bytes_inline_tests::bytes_into_vec_u8 | 1687 | 1020 | 39.54% | | bytes_inline_tests::bytes_is_empty | 722 | 596 | 17.45% | | bytes_inline_tests::bytes_iter | 2194 | 1461 | 33.41% | | bytes_inline_tests::bytes_len | 1047 | 753 | 28.08% | | bytes_inline_tests::bytes_ne | 1233 | 914 | 25.87% | | bytes_inline_tests::bytes_new | 145 | 121 | 16.55% | | bytes_inline_tests::bytes_pop | 2856 | 2029 | 28.96% | | bytes_inline_tests::bytes_ptr | 815 | 620 | 23.93% | | bytes_inline_tests::bytes_push | 1841 | 1233 | 33.03% | | bytes_inline_tests::bytes_raw_slice_from | 716 | 572 | 20.11% | | bytes_inline_tests::bytes_raw_slice_into | 332 | 309 | 6.93% | | bytes_inline_tests::bytes_remove | 1335 | 1038 | 22.25% | | bytes_inline_tests::bytes_remove_all | 932 | 714 | 23.39% | | bytes_inline_tests::bytes_remove_end | 1057 | 845 | 20.06% | | bytes_inline_tests::bytes_remove_front | 1052 | 840 | 20.15% | | bytes_inline_tests::bytes_resize | 4687 | 4081 | 12.93% | | bytes_inline_tests::bytes_set | 1133 | 877 | 22.59% | | bytes_inline_tests::bytes_set_back | 1156 | 900 | 22.15% | | bytes_inline_tests::bytes_set_front | 1133 | 877 | 22.59% | | bytes_inline_tests::bytes_set_twice | 1647 | 1284 | 22.04% | | bytes_inline_tests::bytes_splice | 1883 | 1431 | 24.00% | | bytes_inline_tests::bytes_splice_empty_range | 1365 | 1077 | 21.10% | | bytes_inline_tests::bytes_splice_end | 1385 | 1097 | 20.79% | | bytes_inline_tests::bytes_splice_entire_range | 1368 | 1121 | 18.06% | | bytes_inline_tests::bytes_splice_front | 1363 | 1076 | 21.06% | | bytes_inline_tests::bytes_splice_replace_empty_bytes | 1363 | 1076 | 21.06% | | bytes_inline_tests::bytes_splice_replace_larger | 2264 | 1709 | 24.51% | | bytes_inline_tests::bytes_splice_replace_overlap | 1950 | 1497 | 23.23% | | bytes_inline_tests::bytes_splice_replace_same_length | 1948 | 1495 | 23.25% | | bytes_inline_tests::bytes_splice_replace_smaller | 2198 | 1643 | 25.25% | | bytes_inline_tests::bytes_split_at | 1620 | 1174 | 27.53% | | bytes_inline_tests::bytes_split_at_end | 1423 | 1110 | 22.00% | | bytes_inline_tests::bytes_split_at_front | 1404 | 1088 | 22.51% | | bytes_inline_tests::bytes_split_at_twice | 1619 | 1087 | 32.86% | | bytes_inline_tests::bytes_swap | 1352 | 1034 | 23.52% | | bytes_inline_tests::bytes_swap_end | 1069 | 836 | 21.80% | | bytes_inline_tests::bytes_swap_front | 1068 | 835 | 21.82% | | bytes_inline_tests::bytes_swap_front_with_end | 1069 | 836 | 21.80% | | bytes_inline_tests::bytes_swap_twice | 2003 | 1558 | 22.22% | | bytes_inline_tests::bytes_test_packing | 1325 | 840 | 36.60% | | bytes_inline_tests::bytes_test_u8_limits | 1639 | 1244 | 24.10% | | bytes_inline_tests::bytes_try_into_b256 | 6595 | 3803 | 42.34% | | bytes_inline_tests::bytes_vec_u8_from | 1661 | 995 | 40.10% | | bytes_inline_tests::bytes_vec_u8_into | 2135 | 1092 | 48.85% | | bytes_inline_tests::bytes_with_capacity | 856 | 741 | 13.43% | | bytes_inline_tests::revert_bytes_insert_out_of_bounds | 612 | 484 | 20.92% | | bytes_inline_tests::revert_bytes_remove_out_of_bounds | 585 | 456 | 22.05% | | bytes_inline_tests::revert_bytes_set_out_of_bounds | 587 | 457 | 22.15% | | bytes_inline_tests::revert_bytes_splice_end_out_of_bounds | 696 | 570 | 18.10% | | bytes_inline_tests::revert_bytes_splice_start_greater_than_end | 649 | 523 | 19.41% | | bytes_inline_tests::revert_bytes_split_at_out_of_bounds | 606 | 483 | 20.30% | | bytes_inline_tests::revert_bytes_swap_element_1_out_of_bounds | 587 | 457 | 22.15% | | bytes_inline_tests::revert_bytes_swap_element_2_out_of_bounds | 591 | 461 | 22.00% | | bytes_inline_tests::test_encode_decode | 588 | 619 | -5.27% | | codec_implemented_tests::test_logging | 27189 | 27185 | 0.01% | | contract_id_inline_tests::contract_id_hash | 1648 | 1468 | 10.92% | | contract_id_inline_tests::contract_id_try_from_bytes | 1968 | 1714 | 12.91% | | contract_id_inline_tests::contract_id_try_into_bytes | 11555 | 9566 | 17.21% | | crypto_ed25519_inline_tests::ed25519_hash | 1926 | 1882 | 2.28% | | crypto_ed25519_inline_tests::ed25519_into_bytes | 26703 | 22863 | 14.38% | | crypto_ed25519_inline_tests::ed25519_try_from_bytes | 87153 | 86958 | 0.22% | | crypto_ed25519_inline_tests::ed25519__verify | 13047 | 12823 | 1.72% | | crypto_message_inline_tests::message_bytes | 996 | 787 | 20.98% | | crypto_message_inline_tests::message_eq | 38026 | 32008 | 15.83% | | crypto_message_inline_tests::message_from_b256 | 19321 | 17401 | 9.94% | | crypto_message_inline_tests::message_from_bytes | 3134 | 2516 | 19.72% | | crypto_message_inline_tests::message_hash | 606 | 518 | 14.52% | | crypto_message_inline_tests::message_new | 209 | 186 | 11.00% | | crypto_message_inline_tests::message_try_into_b256 | 1053 | 942 | 10.54% | | crypto_point2d_inline_tests::point2d_b256_array_try_from | 1498 | 1360 | 9.21% | | crypto_point2d_inline_tests::point2d_b256_tuple_try_from | 1457 | 1319 | 9.47% | | crypto_point2d_inline_tests::point2d_from_b256_array | 2591 | 2213 | 14.59% | | crypto_point2d_inline_tests::point2d_from_b256_tuple | 2561 | 2183 | 14.76% | | crypto_point2d_inline_tests::point2d_from_u256_array | 2642 | 2264 | 14.31% | | crypto_point2d_inline_tests::point2d_from_u256_tuple | 2612 | 2234 | 14.47% | | crypto_point2d_inline_tests::point2d_from_u8_array | 19636 | 11386 | 42.01% | | crypto_point2d_inline_tests::point2d_is_zero | 44315 | 36635 | 17.33% | | crypto_point2d_inline_tests::point2d_min | 683 | 603 | 11.71% | | crypto_point2d_inline_tests::point2d_u256_array_try_from | 1549 | 1411 | 8.91% | | crypto_point2d_inline_tests::point2d_u256_tuple_try_from | 1508 | 1370 | 9.15% | | crypto_point2d_inline_tests::point2d_x | 887 | 818 | 7.78% | | crypto_point2d_inline_tests::point2d_y | 890 | 821 | 7.75% | | crypto_point2d_inline_tests::point2d_zero | 683 | 603 | 11.71% | | crypto_public_key_inline_tests::public_key_bytes | 638 | 555 | 13.01% | | crypto_public_key_inline_tests::public_key_eq | 96007 | 80487 | 16.17% | | crypto_public_key_inline_tests::public_key_from_b256 | 19281 | 17361 | 9.96% | | crypto_public_key_inline_tests::public_key_from_b256_tuple | 38468 | 34628 | 9.98% | | crypto_public_key_inline_tests::public_key_from_b512 | 38704 | 34864 | 9.92% | | crypto_public_key_inline_tests::public_key_hash | 606 | 518 | 14.52% | | crypto_public_key_inline_tests::public_key_is_zero | 13201 | 11281 | 14.54% | | crypto_public_key_inline_tests::public_key_new | 209 | 186 | 11.00% | | crypto_public_key_inline_tests::public_key_try_from_bytes | 59073 | 53187 | 9.96% | | crypto_public_key_inline_tests::public_key_try_into_b256 | 1139 | 1070 | 6.06% | | crypto_public_key_inline_tests::public_key_try_into_b256_tuple | 1606 | 1468 | 8.59% | | crypto_public_key_inline_tests::public_key_try_into_b512 | 2043 | 1905 | 6.75% | | crypto_scalar_inline_tests::scalar_b256_try_from | 878 | 809 | 7.86% | | crypto_scalar_inline_tests::scalar_bytes | 633 | 564 | 10.90% | | crypto_scalar_inline_tests::scalar_from_b256 | 1282 | 1093 | 14.74% | | crypto_scalar_inline_tests::scalar_from_u256 | 1306 | 1117 | 14.47% | | crypto_scalar_inline_tests::scalar_from_u8_array | 6978 | 2949 | 57.74% | | crypto_scalar_inline_tests::scalar_is_zero | 22466 | 18626 | 17.09% | | crypto_scalar_inline_tests::scalar_min | 355 | 315 | 11.27% | | crypto_scalar_inline_tests::scalar_new | 181 | 158 | 12.71% | | crypto_scalar_inline_tests::scalar_u256_try_from | 878 | 809 | 7.86% | | crypto_scalar_inline_tests::scalar_zero | 355 | 315 | 11.27% | | crypto_secp256k1_inline_tests::secp256k1_address | 6123 | 6033 | 1.47% | | crypto_secp256k1_inline_tests::secp256k1_evm_address | 6111 | 6021 | 1.47% | | crypto_secp256k1_inline_tests::secp256k1_hash | 1926 | 1882 | 2.28% | | crypto_secp256k1_inline_tests::secp256k1_into_bytes | 26703 | 22863 | 14.38% | | crypto_secp256k1_inline_tests::secp256k1_recover | 21047 | 18441 | 12.38% | | crypto_secp256k1_inline_tests::secp256k1_try_from_bytes | 87153 | 86958 | 0.22% | | crypto_secp256k1_inline_tests::secp256k1_verify | 23267 | 20661 | 11.20% | | crypto_secp256k1_inline_tests::secp256k1_verify_address | 6663 | 6529 | 2.01% | | crypto_secp256k1_inline_tests::secp256k1_verify_evm_address | 6632 | 6498 | 2.02% | | crypto_secp256r1_inline_tests::secp256r1_address | 10221 | 10131 | 0.88% | | crypto_secp256r1_inline_tests::secp256r1_evm_address | 10209 | 10119 | 0.88% | | crypto_secp256r1_inline_tests::secp256r1_hash | 1926 | 1882 | 2.28% | | crypto_secp256r1_inline_tests::secp256r1_into_bytes | 26703 | 22863 | 14.38% | | crypto_secp256r1_inline_tests::secp256r1_recover | 25145 | 22539 | 10.36% | | crypto_secp256r1_inline_tests::secp256r1_try_from_bytes | 87153 | 86958 | 0.22% | | crypto_secp256r1_inline_tests::secp256r1_verify | 27941 | 25295 | 9.47% | | crypto_secp256r1_inline_tests::secp256r1_verify_address | 10761 | 10627 | 1.25% | | crypto_secp256r1_inline_tests::secp256r1_verify_evm_address | 11051 | 10917 | 1.21% | | crypto_signature_inline_tests::signature_address | 11056 | 10878 | 1.61% | | crypto_signature_inline_tests::signature_evm_address | 11032 | 10854 | 1.61% | | crypto_signature_inline_tests::signature_recover | 41145 | 35935 | 12.66% | | crypto_signature_inline_tests::signature_verify | 46227 | 40971 | 11.37% | | crypto_signature_inline_tests::signature_verify_address | 11106 | 10928 | 1.60% | | crypto_signature_inline_tests::signature_verify_evm_address | 11105 | 10927 | 1.60% | | crypto_zk_inline_tests::revert_zk_alt_bn128_add_fail | 4499 | 4407 | 2.04% | | crypto_zk_inline_tests::revert_zk_alt_bn128_mul_fail | 4264 | 4195 | 1.62% | | crypto_zk_inline_tests::revert_zk_alt_bn128_pairing_check | 123487 | 123269 | 0.18% | | crypto_zk_inline_tests::zk_alt_bn128_add | 105641 | 92381 | 12.55% | | crypto_zk_inline_tests::zk_alt_bn128_mul | 104468 | 91323 | 12.58% | | crypto_zk_inline_tests::zk_alt_bn128_pairing_check | 1146355 | 1142872 | 0.30% | | ecr_inline_tests::ecr_ec_recover_address | 3721 | 3533 | 5.05% | | ecr_inline_tests::ecr_ec_recover_address_r1 | 7819 | 7631 | 2.40% | | ecr_inline_tests::ecr_ed_verify | 20067 | 15455 | 22.98% | | hash_inline_tests::hash_hasher_keccak256_b256 | 970 | 882 | 9.07% | | hash_inline_tests::hash_hasher_keccak256_bool | 797 | 627 | 21.33% | | hash_inline_tests::hash_hasher_keccak256_bytes | 749 | 579 | 22.70% | | hash_inline_tests::hash_hasher_keccak256_str | 973 | 885 | 9.04% | | hash_inline_tests::hash_hasher_keccak256_str_array | 936 | 848 | 9.40% | | hash_inline_tests::hash_hasher_keccak256_u16 | 938 | 850 | 9.38% | | hash_inline_tests::hash_hasher_keccak256_u256 | 970 | 882 | 9.07% | | hash_inline_tests::hash_hasher_keccak256_u32 | 938 | 850 | 9.38% | | hash_inline_tests::hash_hasher_keccak256_u64 | 936 | 848 | 9.40% | | hash_inline_tests::hash_hasher_keccak256_u8 | 794 | 624 | 21.41% | | hash_inline_tests::hash_hasher_sha256_10_array | 11064 | 8384 | 24.22% | | hash_inline_tests::hash_hasher_sha256_1_array | 972 | 884 | 9.05% | | hash_inline_tests::hash_hasher_sha256_2_array | 2092 | 1716 | 17.97% | | hash_inline_tests::hash_hasher_sha256_3_tuple | 3172 | 2508 | 20.93% | | hash_inline_tests::hash_hasher_sha256_4_array | 4300 | 3348 | 22.14% | | hash_inline_tests::hash_hasher_sha256_4_tuple | 4276 | 3324 | 22.26% | | hash_inline_tests::hash_hasher_sha256_5_array | 5404 | 4164 | 22.95% | | hash_inline_tests::hash_hasher_sha256_5_tuple | 5380 | 4140 | 23.05% | | hash_inline_tests::hash_hasher_sha256_6_array | 6591 | 5063 | 23.18% | | hash_inline_tests::hash_hasher_sha256_8_array | 8827 | 6723 | 23.84% | | hash_inline_tests::hash_hasher_sha256_9_array | 9945 | 7553 | 24.05% | | hash_inline_tests::hash_hasher_sha256_b256 | 952 | 864 | 9.24% | | hash_inline_tests::hash_hasher_sha256_bool | 779 | 609 | 21.82% | | hash_inline_tests::hash_hasher_sha256_bytes | 809 | 637 | 21.26% | | hash_inline_tests::hash_hasher_sha256_u16 | 920 | 832 | 9.57% | | hash_inline_tests::hash_hasher_sha256_u256 | 952 | 864 | 9.24% | | hash_inline_tests::hash_hasher_sha256_u32 | 920 | 832 | 9.57% | | hash_inline_tests::hash_hasher_sha256_u64 | 918 | 830 | 9.59% | | hash_inline_tests::hash_hasher_sha256_u8 | 776 | 606 | 21.91% | | hash_inline_tests::hash_hasher_write_str | 955 | 867 | 9.21% | | hash_inline_tests::hash_hasher_write_str_array | 918 | 830 | 9.59% | | hash_inline_tests::hash_keccak256 | 997 | 909 | 8.83% | | hash_inline_tests::hash_sha256 | 979 | 891 | 8.99% | | hash_inline_tests::hash_sha256_str_array | 950 | 862 | 9.26% | | identity_inline_tests::identity_hash | 5227 | 3613 | 30.88% | | primitive_conversions_b256_inline_tests::b256_from_u128 | 677 | 572 | 15.51% | | primitive_conversions_b256_inline_tests::b256_into_u128 | 677 | 572 | 15.51% | | primitive_conversions_b256_inline_tests::b256_try_from_bytes | 8510 | 4472 | 47.45% | | string_inline_tests::string_as_bytes | 1050 | 745 | 29.05% | | string_inline_tests::string_as_raw_slice | 1020 | 733 | 28.14% | | string_inline_tests::string_bytes_from | 1484 | 1013 | 31.74% | | string_inline_tests::string_bytes_into | 1484 | 1013 | 31.74% | | string_inline_tests::string_capacity | 602 | 436 | 27.57% | | string_inline_tests::string_clear | 485 | 365 | 24.74% | | string_inline_tests::string_clone | 2747 | 1879 | 31.60% | | string_inline_tests::string_from_ascii | 1733 | 1245 | 28.16% | | string_inline_tests::string_from_ascii_str | 1246 | 1025 | 17.74% | | string_inline_tests::string_from_bytes | 1484 | 1013 | 31.74% | | string_inline_tests::string_from_raw_slice | 1391 | 1044 | 24.95% | | string_inline_tests::string_into_bytes | 2080 | 1449 | 30.34% | | string_inline_tests::string_into_raw_slice | 1509 | 1227 | 18.69% | | string_inline_tests::string_is_empty | 1100 | 818 | 25.64% | | string_inline_tests::string_new | 196 | 173 | 11.73% | | string_inline_tests::string_ptr | 1169 | 790 | 32.42% | | string_inline_tests::string_raw_slice_from | 1020 | 733 | 28.14% | | string_inline_tests::string_raw_slice_into | 1020 | 733 | 28.14% | | string_inline_tests::string_test_abi_encoding | 939 | 861 | 8.31% | | string_inline_tests::string_test_equal | 1227 | 1071 | 12.71% | | string_inline_tests::string_test_hash | 983 | 775 | 21.16% | | string_inline_tests::string_with_capacity | 2484 | 2047 | 17.59% | | u128_inline_tests::u128_as_u256 | 10083 | 8974 | 11.00% | | vec_inline_tests::revert_vec_insert_out_of_bounds | 655 | 527 | 19.54% | | vec_inline_tests::revert_vec_remove_out_of_bounds | 629 | 501 | 20.35% | | vec_inline_tests::revert_vec_set_out_of_bounds | 631 | 501 | 20.60% | | vec_inline_tests::revert_vec_swap_element_1_out_of_bounds | 632 | 501 | 20.73% | | vec_inline_tests::revert_vec_swap_element_2_out_of_bounds | 636 | 505 | 20.60% | | vec_inline_tests::vec_as_raw_slice | 758 | 587 | 22.56% | | vec_inline_tests::vec_buffer_ownership | 2325 | 1607 | 30.88% | | vec_inline_tests::vec_capacity | 1103 | 755 | 31.55% | | vec_inline_tests::vec_clear | 631 | 505 | 19.97% | | vec_inline_tests::vec_clear_empty_vec | 189 | 143 | 24.34% | | vec_inline_tests::vec_clear_twice | 735 | 567 | 22.86% | | vec_inline_tests::vec_clone | 1798 | 1376 | 23.47% | | vec_inline_tests::vec_encode_and_decode | 2527 | 1893 | 25.09% | | vec_inline_tests::vec_from_raw_slice | 310 | 287 | 7.42% | | vec_inline_tests::vec_get | 1613 | 1367 | 15.25% | | vec_inline_tests::vec_insert | 1466 | 1171 | 20.12% | | vec_inline_tests::vec_insert_back | 1467 | 1172 | 20.11% | | vec_inline_tests::vec_insert_before_back | 1478 | 1183 | 19.96% | | vec_inline_tests::vec_insert_front | 1477 | 1182 | 19.97% | | vec_inline_tests::vec_insert_twice | 2493 | 2032 | 18.49% | | vec_inline_tests::vec_is_empty | 742 | 616 | 16.98% | | vec_inline_tests::vec_iter | 2303 | 1656 | 28.09% | | vec_inline_tests::vec_last | 1623 | 1313 | 19.10% | | vec_inline_tests::vec_len | 1179 | 885 | 24.94% | | vec_inline_tests::vec_new | 119 | 96 | 19.33% | | vec_inline_tests::vec_pop | 3292 | 2456 | 25.39% | | vec_inline_tests::vec_ptr | 834 | 639 | 23.38% | | vec_inline_tests::vec_push | 2022 | 1414 | 30.07% | | vec_inline_tests::vec_raw_slice_into | 310 | 287 | 7.42% | | vec_inline_tests::vec_remove | 1475 | 1178 | 20.14% | | vec_inline_tests::vec_remove_all | 1048 | 830 | 20.80% | | vec_inline_tests::vec_remove_end | 1152 | 940 | 18.40% | | vec_inline_tests::vec_remove_front | 1155 | 943 | 18.35% | | vec_inline_tests::vec_resize | 5107 | 4437 | 13.12% | | vec_inline_tests::vec_set | 1244 | 988 | 20.58% | | vec_inline_tests::vec_set_back | 1267 | 1011 | 20.21% | | vec_inline_tests::vec_set_front | 1244 | 988 | 20.58% | | vec_inline_tests::vec_set_twice | 1827 | 1464 | 19.87% | | vec_inline_tests::vec_swap | 1541 | 1202 | 22.00% | | vec_inline_tests::vec_swap_end | 1221 | 967 | 20.80% | | vec_inline_tests::vec_swap_front | 1220 | 966 | 20.82% | | vec_inline_tests::vec_swap_front_with_end | 1221 | 967 | 20.80% | | vec_inline_tests::vec_swap_twice | 2319 | 1832 | 21.00% | | vec_inline_tests::vec_with_capacity | 3078 | 2963 | 3.74% | | vm_evm_ecr_inline_tests::ecr_ec_recover | 3416 | 3185 | 6.76% | | vm_evm_evm_address_inline_tests::evm_address_hash | 1904 | 1708 | 10.29% | | vm_evm_evm_address_inline_tests::evm_address_into_bytes | 7827 | 6558 | 16.21% | | vm_evm_evm_address_inline_tests::evm_address_try_from_bytes | 3111 | 2340 | 24.78% | </details> ## 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-05-08 07:25:02 +00:00
saimeunt	47c2fc4c9b	Support doc comments and attributes on nested items (#7146) ... ## Description This PR adds support for nested annotations and doc comments. Closes #6932 ## 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> Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2025-05-08 04:40:32 +00:00
Cameron Carstens	f9fcae93c1	Support new expiry policy in std-lib (#7155) ... ## Description Adds support for the new expiry policy gtf in the std-lib. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-05-07 14:53:18 +04:00
João Matos	f635cc22ea	Remove AbiEncode impl for raw_ptr (#7160) ... This was added originally in https://github.com/FuelLabs/sway/pull/6844 but should not have been introduced in the first place. I added this while in development for the trait coherence feature but its not necessary and not something we wish to support in the public ABI surface. Fixes https://github.com/FuelLabs/sway/issues/7153. Thanks to @ironcev for catching this. Co-authored-by: IGI-111 <igi-111@protonmail.com>	2025-05-06 13:12:26 +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