This adds a new `--dump-impls` CLI command that can be used to dump all
the recognized trait impls for a given type name.
This also extends the compiler diagnostic system to allow the emission
of info diagnostics, as previously we could only emit either warnings of
errors, which did not fit this use case.
## Description
For example, here is the output of `cargo run --bin forc -- build --path
_test-case --dump-impls=std::string::String`:
<img width="677" height="958" alt="image"
src="https://github.com/user-attachments/assets/42aeca94-bbf9-4dff-8bb3-d1a70000999a"
/>
And for enums:
<img width="642" height="285" alt="image"
src="https://github.com/user-attachments/assets/ac565fea-9ebe-4f1d-a9a8-d022617d23d0"
/>
Closes https://github.com/FuelLabs/sway/issues/7286.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
This PR adds the `backtrace` build option as described in the [ABI
Backtracing
RFC](https://github.com/FuelLabs/sway-rfcs/blob/ironcev/abi-backtracing/rfcs/0016-abi-backtracing.md).
This is the second step in implementing #7276.
Docs for `backtrace` build option will be added in a separate PR that
will document the whole backtracking feature.
## Checklist
- [x] I have linked to any relevant issues.
- [ ] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## 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>
## Description
Updates all the dependencies for the current release.
Implements the fuel ABI generation changes proposed in
https://github.com/FuelLabs/fuel-specs/pull/599.
Removes the flag `--json-abi-with-callpaths` and the behavior is as if
it were true. We removed the flag because it is unsafe to produce JSON
ABIs without callpaths, so we shouldn't allow it.
Includes the LDC, BSIZ, BLDD and ED19 changes
from:https://github.com/FuelLabs/sway/pull/6409.
Fixes https://github.com/FuelLabs/sway/issues/5954
Fixes https://github.com/FuelLabs/sway/issues/5151
## 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: Vaivaswatha Nagaraj <vaivaswatha.nagaraj@fuel.sh>
Co-authored-by: Kaya Gokalp <kayagokalp123@gmail.com>
Co-authored-by: Kaya Gökalp <kaya.gokalp@fuel.sh>
Co-authored-by: Igor Rončević <ironcev@hotmail.com>
Co-authored-by: IGI-111 <igi-111@protonmail.com>
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
## Description
This PR:
- implements detailed control over printing of IR:
- initial IR
- IR after choosen optimization steps, with option to print only the
steps that have actually modified the IR
- final IR
- improves printed IRs by removing the confusing empty modules printed
for every external library dependency.
- harmonizes names and descriptions of the optimization passes. The
proposed convention is documented in the
_sway-ir/src/optimize/README.md_ file.
- harmonizes help comments of the shared compiler options (consistent
separation between option title and additional info, wording, etc.)
## Demo
```
'Print initial and final IR together with IR after each optimization step.
--ir all
'Print initial and final IR together with IR after each optimization step that has modified the IR.
--ir all modified
'Print only the final IR.
--ir final
'Print the IR after every "dce", "sroa", and "inline" optimization step.
--ir dce sroa inline
'Print the IR after every "dce", "sroa", and "inline" optimization step that has modified the IR.
--ir dce sroa inline modified
```
## Breaking Changes
### CLI
Instead of the existing `--ir` option without parameters we now have the
same CLI option but with parameters. The existing `--ir` is equivalent
to the new `--ir final`.
### Build Profile
Instead of the existing `print-ir` of type bool, we now have the same
`print-ir` build profile option with parameters. E.g.:
```
print-ir = { initial = true, final = false, modified = true, passes = ["dce", "sroa"]}
```
## Checklist
- [ ] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
This PR simplifies and gives more control ove printing the ASM. It's a
first step in harmonizing printing options for ASM and IR, where the
goal is to be able to print arbitrary optimization passes in IR.
This PR:
- replaces two existing, verbose and unintuitive to discover, ASM
printing CLI options with a single `--asm`, same as the single `--ir`
option.
- improves printed ASM by removing the confusing empty programs printed
for every external library dependency.
- harmonizes printed virtual and allocated abstract ASM to have the
same-looking comments and structure.
Additionally, the PR fixes the bug in the
`PassManager::insert_after_each` helper function, where passes were not
inserted within groups. This is a preparation step for the changes
needed for improving the `--ir` CLI option.
## Demo
```
--asm all 'Prints virtual, allocated, and final ASM.
--asm final 'Prints only the final ASM.
--asm allocated final 'Prints the allocated and the final ASM.
```
## Breaking Changes
### CLI
Instead of existing `--intermediate-asm` and `--finalized-asm` options
we now have a single `--asm` CLI option with parameters. The existing
options should be replaced:
| Current | New |
| - | - |
|`--intermediate-asm`|`--asm abstract`|
|`--finalized-asm`|`--asm final`|
|`--intermediate-asm --finalized-asm`|`--asm all`|
### Build Profile
Instead of existing `print-intermediate-asm` and `print-finalized-asm`
options we now have a single `print-asm` CLI option with parameters.
E.g.:
```
print-asm = { virtual = true, allocated = true, final = true }
```
## Checklist
- [ ] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] 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.
## Description
This PR fixes a bunch of issues we had in generating access to the data
section. It also fixes#5876.
Reverts #5918.
---------
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
Closes https://github.com/FuelLabs/sway/issues/5607
Solves part [1] of https://github.com/FuelLabs/sway/issues/5607 by
making "release" the default build plan for forc-deploy. It can still be
overridden, i.e. for the test harness.
Other changes:
- removed the `--release` and `--error-on-warnings` options from
forc-deploy, since those aren't needed.
- refactored `BuildProfile` into its own file and added a test, since I
noticed some of the options weren't deserializing
## 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).
- [ ] 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.
## Description
Take the cargo approach of ignoring patches of workspace members,
printing a warning, and only accepting patches defined at the workspace
root file.
Fixes#4448
## 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] 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.
## Description
Fixes#1645 by checking if there are any duplicate keys in sections. Any
duplication of keys will generate a parsing error that will bubble up to
the final user with some context on how to fix it.
The following `Forc.toml` file will fail:
```
[project]
authors = ["Cesar"]
entry = "main.sw"
license = "Apache-2.0"
name = "invalid"
[dependencies]
foo = "bar"
foo = "xxx"
```
The error that will be bubble up to the CLI output reads as follow:
```
Error: failed to parse manifest: duplicate 'foo' for key `dependencies` at line 7 column 1.
```
