13 commits

Author	SHA1	Message	Date
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
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
Igor Rončević	74282e2c7b	Defining, parsing, and checking #[attribute]s (#6986) ... ## Description This PR reimplements how `#[attribute]`s are parsed, defined, and checked. It fixes the following issues we had with attributes: - attributes were in general not checked for their expected and allowed usage. - when checked, checks were fixing particular reported issues and were scattered through various compilation phases: lexing, parsing, and tree conversion. - when checked, reported errors in some cases had bugs and were overalapping with other errors and warnings. - attribute handling was not centralized, but rahter scattered throught the whole code base, and mostly done at use sites. For concrete examples of these issues, see the list of closed issues below. The PR: - encapsulates the attributes handling within a single abstraction: `Attributes`. - assigns the following properties to every attribute: - _target_: what kind of elements an attribute can annotate. - _multiplicity_: if more then one attribute of the same kind can be applied to an element. - _arguments multiplicity_: a range defining how many arguments an attribute can or must have. - _arguments value expectation_: if attribute arguments are expected to have values. - validates those properties in a single place, during the `convert_parse_tree`. Note that this means that modules with attribute issues will now consistently not reach the type checking phase. This was previously the case for some of the issues with attributes where custom checks where done during the type checking phase. #6987 proposes to move those checks after the tree conversion phase, allowing the continuation of compilation. - adds the `AttributeKind::Unknow` to preserve unknown attributes in the typed tree. - removes redundant code related to attributes: specific warnings and errors, specialized parsing, repetitive and error-prone at use site checks, etc. - removes the unused `Doc` attribute. The PR also introduces a new pattern in emitting errors. The `attr_decls_to_attributes` function will always return `Attributes` even if they have errors, because: - we expect the compilation to continue even in the case of errors. - we expect those errors to be ignored if a valid `#[cfg]` attribute among those evaluates to false. - we expect them to be emitted with eventual other errors, or alone, at the end of the tree conversion of the annotated element. For more details, see the comment on `attr_decls_to_attributes` and `cfg_eval`. Closes #6880; closes #6913; closes #6914; closes #6915; closes #6916; closes #6917; closes #6918; closes #6931; closes #6981; closes #6983; closes #6984; closes #6985. ## Breaking changes Strictly seen, this PR can cause breaking changes, but only in the case of invalid existing attribute usage. We treat those breaking changes as bug fixes in the compiler and, thus, do not have them behind a feature flag. E.g., this kind of code was possible before, but will now emit and error: ```sway #[storage(read, write, read, write)] struct Struct {} ``` ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-03-24 09:34:31 +11:00
Igor Rončević	58114d7e68	Promote experimental features (#7016) ... ## Description This PR promotes the following experimental features to standard ones: - #6701 - #6883 - #6994 - #7006 Additionally, the PR stenghtens the migration infrastructure by checking some additional cases in selecting corresponding typed elements in desugared code which were not checked before. Closes #6701. Closes #6883. Closes #6994. Closes #7006. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-03-13 20:47:01 +11:00
IGI-111	d22ff45869	Fix source dependencies preventing release (#7012) ... ## Description The sway-features Cargo.toml had dependencies not aligned with the workspace which prevented the publish action to run properly. ## Checklist - [ ] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers.	2025-03-11 18:54:51 +04:00
Igor Rončević	c8c4d2bb3b	Add migration for merging core and std libraries (#7010) ... ## Description This PR adds migration step for merging `core` and `std` libraries, as explained in the Breaking Changes chapter of #7006. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-03-11 10:51:45 +00:00
Cameron Carstens	be5ecbd692	Implement TryFrom<Bytes> for b256 (#6958) ... ## Description `impl From<Bytes> for b256` has been removed and replaced with `impl TryFrom<Bytes> for b256` increasing saftey when converting between the two types. `impl Into<Bytes> for b256` and `impl TryInto<b256> for Bytes` have also been added. This PR breaks the following implementation: ```sway let mut my_bytes = Bytes::new(); my_bytes.push(1u8); let result: b256 = b256::from(my_bytes); ``` The implementation should now be: ```sway let mut my_bytes = Bytes::new(); my_bytes.push(1u8); // Option 1 let result_1: Option<b256> = b256::try_from(my_bytes); // Option 2 let result_2 = my_bytes.try_into(); ``` Closes #6994. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: Igor Rončević <ironcev@hotmail.com>	2025-03-05 17:20:13 +04:00
Daniel Frederico Lins Leite	d8854fad08	Const generic feature toggle, parser and errors. (#6926) ... ## Description This PR is part of https://github.com/FuelLabs/sway/issues/6860, and it is officially introducing the `const_generic` feature toggle. For the moment, it is parsing syntax such as `const N: u64` and it is returning an error explaining that the feature is off; on the other hand, it is also returning an error saying that const generics are still not supported in impl traits when the feature is on. Future PRs will replicate this error in all possible places. Nothing else is implemented and it is reserved for future PRs. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [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-02-18 09:28:19 +11:00
Igor Rončević	bb7c99b24a	Implement partial equivalence and extend forc migrate tool (#6900) ... ## Description This PR: - implements partial equivalence in the `core::ops`, as explained in detail in #6883. The implementation is opt-in and behind the `partial_eq` experimental feature flag. - implements `forc migrate` migration steps for automatic migration to `partial_eq` feature. - extends the infrastructure for writing `forc migrate` migrations. - preserves `Annotation`s on `LexedModule`s in the `LexedProgram`. (Those were before stripped off and not available in the compiled `Programs`. This resulted in loss off `//!` doc-comments that are represented as `doc-comment` annotations.) Extensions in the `forc migrate` infrastructure include: - possibility to postpone migration steps. This allows writing multi-step migrations where the first step is usually early adopting an experimental feature by using `cfg` attributes in code. This possibility is crucial for migrating our own codebase where we want to early-adopt and test and stabilize experimental features. - possibility to match elements on both mutable and immutable parsed trees. The initial assumption that immutable matching on typed trees will always be sufficient does not hold. Experimental `cfg` attributes can remove parts of typed trees that might be needed in analysis. - `LexedLocate(As)Annotated` for easier location and retrieval of `Annotated` elements. - additional implementations of existing traits. - additional `Modifier`s for modifying existing elements in the lexed tree. - `New` struct for convenient creation of often needed lexed tree elements. Note that we do not expect migrations to generate large new parts of lexed trees, but mostly to modify or copy and modify existing ones. Almost all of the changes in the Sway files are done automatically by the migration steps. The only manual change was in the `core` library (`std` library is also automatically migrated) and in slight extension of two of the tests. Note that some of the tests have `Eq` traits in trait constraints. As explained in the #6883, it is not necessary to change those to `PartialEq`. We might consider changing some of them, for testing purposes, and such a change is done on one of the tests that was testing the behavior of the `Eq` trait. But for the majority of the tests, there is no strict need for switching from `Eq` to `PartialEq`. Rolling `PartialEq` out in the tests provoked three existing issues that will be fixed in separate PRs: #6897, #6898, #6899. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-02-11 10:02:45 -03:00
Igor Rončević	1270bfa53f	Marker traits (#6871) ... ## Description This PR introduces the concept of marker traits to the language. It is the first step towards implementing the [ABI errors RFC](https://github.com/FuelLabs/sway-rfcs/blob/master/rfcs/0014-abi-errors.md). Marker traits are traits automatically generated by the compiler. They represent certain properties of types and cannot be explicitly implemented by developers. The PR implements a common infrastructure for generating and type-checking marker traits as well as two concrete marker traits: - `Error`: represents a type whose instances can be used as arguments for the `panic` expression. (The `panic` expression is yet to be implemented.) - `Enum`: represents an enum type. Combining these two marker traits in trait constraints allow expressing constraints such is, e.g., "the error type must be an error enum": ``` fn panic_with_error<E>(err: E) where E: Error + Enum { panic err; } ``` Note that the generic name `Enum` is sometimes used in our tests to represent a dummy enum. In tests, it is almost always defined locally, and sometimes explicitly imported, so it will never clash with the `Enum` marker trait. A single test in which the clash occurred was easily adapted by explicitly importing the dummy `Enum`. The PR is the first step in implementing #6765. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-02-07 03:25:57 +00:00
Igor Rončević	7aa59f987c	Add forc-migrate tool (#6790) ... ## Description This PR introduces `forc-migrate`, a Forc tool for migrating Sway projects to the next breaking change version of Sway. The tool addresses two points crucial for code updates caused by breaking changes: - it informs developers about the breaking changes and **assists in planing and executing** the migration. - it **automatically changes source code** where possible, reducing the manual effort needed for code changes. Besides adding the `forc-migrate` tool, the PR: - extends `Diagnostic` to support migration diagnostics aside with errors and warnings. - changes `swayfmt` to support generating source code from arbitrary lexed trees. The change is a minimal one done only in the parts of `swayfmt` that are executed by migration steps written in this PR. Adapting `swayfmt` to fully support arbitrary lexed trees will be done in #6779. The migration for the `references` feature, migrating `ref mut` to `&mut`, is developed only partially, to demonstrate the development and usage of automatic migrations that alter the original source code. The intended usage of the tool is documented in detail in the "forc migrate" chapter of The Sway Book: _Forc reference > Plugins > forc_migrate_. (The generated documentation has issues that are caused by the documentation generation bug explained in #6792. These issues will be fixed in a separate PR that will fix it for all the plugins.) We expect the `forc-migrate` to evolve based on the developer's feedback. Some of the possible extensions of the tool are: - adding additional CLI options, e.g., for executing only specific migration steps, or ignoring them. - passing parameters to migration steps from the CLI. - not allowing updates by default, if the repository contains modified or untracked files. - migrating workspaces. - migrating other artifacts, e.g., Forc.toml files or contract IDs. - migrating between arbitrary versions of Sway. - migrating SDK code. - etc. `forc-migrate` also showed a clear need for better infrastructure for writing static analyzers and transforming Sway code. The approach used in the implementation of this PR should be seen as a pragmatic beginning, based on the reuse of what we currently have. Some future options are discussed in #6836. ## Demo ### `forc migrate show` Shows the breaking change features and related migration steps. This command can be run anywhere and does not require a Sway project. ``` Breaking change features: - storage_domains (https://github.com/FuelLabs/sway/issues/6701) - references (https://github.com/FuelLabs/sway/issues/5063) Migration steps (1 manual and 1 semiautomatic): storage_domains [M] Review explicitly defined slot keys in storage declarations (`in` keywords) references [S] Replace `ref mut` function parameters with `&mut` Experimental feature flags: - for Forc.toml: experimental = { storage_domains = true, references = true } - for CLI: --experimental storage_domains,references ``` ### `forc migrate check` Performs a dry-run of the migration on a concrete Sway project. It outputs all the occurrences in code that need to be reviewed or changed, as well as the migration time effort: ``` info: [storage_domains] Review explicitly defined slot keys in storage declarations (`in` keywords) --> /home/kebradalaonda/Desktop/M Forc migrate tool/src/main.sw:19:10 | ... 19 | y in b256::zero(): u64 = 0, | ------------ 20 | z: u64 = 0, 21 | a in calculate_slot_address(): u64 = 0, | ------------------------ 22 | b in 0x0102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f20: u64 = 0, | ------------------------------------------------------------------ | = help: If the slot keys used in `in` keywords represent keys generated for `storage` fields = help: by the Sway compiler, those keys might need to be recalculated. = help: = help: The previous formula for calculating storage field keys was: `sha256("storage.<field name>")`. = help: The new formula is: `sha256((0u8, "storage.<field name>"))`. = help: = help: For a detailed migration guide see: https://github.com/FuelLabs/sway/issues/6701 ____ Migration effort: storage_domains [M] Review explicitly defined slot keys in storage declarations (`in` keywords) Occurrences: 3 Migration effort (hh::mm): ~00:06 references [S] Replace `ref mut` function parameters with `&mut` Occurrences: 0 Migration effort (hh::mm): ~00:00 Total migration effort (hh::mm): ~00:06 ``` ### `forc migrate run` Runs the migration steps and guides developers through the migration process. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-01-20 13:14:20 +01:00
Igor Rončević	3b07f499c2	Storage domains (#6466) ... ## Description This PR fixes #6317 by implementing `storage_domains` experimental feature. This feature introduces two _storage domains_, one for the storage fields defined inside of the `storage` declaration, and a different one for storage slots generated inside of the `StorageMap`. The PR strictly fixes the issue described in #6317 by applying the recommendation proposed in the issue. A general approach to storage key domains will be discussed as a part of the [Configurable and composable storage RFC](https://github.com/FuelLabs/sway-rfcs/pull/40). Additionally, the PR: - adds expressive diagnostics for the duplicated storage keys warning. - removes the misleading internal compiler error that always followed the storage key type mismatch error (see demo below). Closes #6317, #6701. ## Breaking Changes The PR changes the way how storage keys are generated for `storage` fields. Instead of `sha256("storage::ns1::ns2.field_name")` we now use `sha256((0u8, "storage::ns1::ns2.field_name"))`. This is a breaking change for those who relied on the storage key calculation. ## Demo Before, every type-mismatch was always followed by an ICE, because the compilation continued despite the type-mismatch.  This is solved now, and the type-mismatch has a dedicated help message.  ## 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: Sophie Dankel <47993817+sdankel@users.noreply.github.com> Co-authored-by: IGI-111 <igi-111@protonmail.com>	2024-11-15 04:46:56 +01:00
Daniel Frederico Lins Leite	ddb505d263	migrate encoding v1 to sway-features (#6586) ... ## Description This PR starts the implementation of https://github.com/FuelLabs/sway-rfcs/blob/master/rfcs/0013-changes-lifecycle.md. ## CLI flags Now, all `CLI`s, including our tests, support two new arguments ``` ... --experimental <EXPERIMENTAL> Comma separated list of all experimental features that will be enabled [possible values: new_encoding, storage_domains] --no-experimental <NO_EXPERIMENTAL> Comma separated list of all experimental features that will be disabled [possible values: new_encoding, storage_domains] ... ``` Experimental features can also be enabled inside `Forc.toml` for workspaces and individual projects. ``` experimental = { encoding-v1 = true } ``` And can be enabled using environment variables: ``` FORC_NO_EXPERIMENTAL=feature_a,feature_b FORC_EXPERIMENTAL=feature_c forc build ... ``` These configurations are applied in a very specific order to allow them to be overwritten. The order from the weakest to the strongest is: 1 - Workspace `TOML` 2 - Project `TOML` 3 - CLI 4 - Environment variables. The rationale is: 1 - We want an easy way to enable and/or disable a feature for the whole workspace; 2 - But we want to allow projects to overwrite these features, when needed. These two are the suggested approach to configure experimental features, but we also want to allow someone to easily turn on or off features to test something in particular. For that one can use the CLI flags; and in the specific case one does not have access to the CLI, for example, when one of the `SDK` is compiling the code, one can still completely overwrite the `TOML` files using environment variables. We are also applying the "no experimental" first. This is to allow the use case of exactly controlling which features will be enabled and disabled. In this case one can use the "meta-feature" `all` to disable everything and enable only the desired features. For example: ``` FORC_NO_EXPERIMENTAL=all FORC_EXPERIMENTAL=new_encoding your_command.... ``` ## Test for "-h" This PR also introduces snapshot tests for "-h" for all forc commands at https://github.com/FuelLabs/sway/pull/6586/files#diff-20a5e677d2ae9266a2247739b6a473d2ad0c627955187d668822e7d194f8e940 ## Multiple test.toml This PR also enables the use of multiple `test.toml`. Now each `test.toml` will be a different test, allowing the same code to be compiled and asserted differently. For example, `main_args_empty` has two files: the normal `test.toml` and a new `test.encoding_v1.toml`. One has `new_encoding` enabled and the other disabled. When a `test.toml` file has the `experimental` field, we do not use fields with `_new_encoding` suffix anymore, making these files simpler: test.toml: ```toml category = "run" # (1336, 1) script_data = "0000000000000538 0000000000000001" expected_result = { action = "return", value = 1337 } validate_abi = true experimental = { encoding_v1 = false } ``` test.encoding_v1.toml ``` script_data = "0000000000000538 0000000000000001" expected_result = { action = "return_data", value = "0000000000000539" } experimental = { new_encoding = true } ``` Test tomls with a suffix use `test.toml` as a base. So we do not need to repeat every field in them. Now when we run a test, we will see two tests instead of just one: ``` ... Testing should_pass/language/main_args/main_args_empty (test.encoding_v1.toml) ... ok Testing should_pass/language/main_args/main_args_empty (test.toml) ... ok ... ``` ## Conditional compilation It is also possible to use conditional compilation using these experimental features. Examples can be found inside `sway-lib-std`. ```sway #[cfg(experimental_new_encoding = true)] pub fn assert_eq<T>(v1: T, v2: T) { ... } ``` ## Checklist - [ ] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: IGI-111 <igi-111@protonmail.com>	2024-10-28 11:34:03 +01:00