## 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.
## 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>
## 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>
## 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>
## 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.
## Description
This PR implements the `__dbg(...)` intrinsic, which is very similar to
Rust `dbg!(...)` macro.
Up until now, it has being the norm to use `__log` to debug values.
Given that this is NOT the first use case for log, we have always found
some issues with it: log does not work on predicates, log does not show
"private" fields like `Vec::capacity` and others.
To solve these problems `__dbg` is being introduced:
1 - it will work on all program types, including predicates;
2 - it also prints the file name, line and column;
3 - All types will have an automatic implementation of Debug if
possible, which can still be customized.
4 - Even `raw_ptr` and other non "loggable" types, have `Debug` impls.
5 - `__dbg` will be completely stripped in the release build by default.
It can be turned on again if needed.
So this:
```
// Aggregates
let _ = __dbg((1u64, 2u64));
let _ = __dbg([1u64, 2u64]);
// Structs and Enums
let _ = __dbg(S { });
let _ = __dbg(E::None);
let _ = __dbg(E::Some(S { }));
```
will generate this:
```
[src/main.sw:19:13] = (1, 2)
[src/main.sw:20:13] = [1, 2]
[src/main.sw:23:13] = S { }
[src/main.sw:24:13] = None
[src/main.sw:25:13] = E(S { })
```
How does this work?
`__dbg(value)` intrinsic is desugared into `{ let f = Formatter{};
f.print_str(...); let value = value; value.fmt(f); value }`.
`Formatter` is similar to Rust's one. The difference is that we still do
not support string formatting, so the `Formatter` has a lot of `print_*`
functions.
And each `print` function calls a "syscall". This `syscall` uses `ecal`
under the hood and it follows unix write syscall schema.
```sway
// ssize_t write(int fd, const void buf[.count], size_t count);
fn syscall_write(fd: u64, buf: raw_ptr, count: u64) {
asm(id: 1000, fd: fd, buf: buf, count: count) {
ecal id fd buf count;
}
}
```
For that to work, the VM interpreter must have its `EcalState` setup and
interpret syscall number 1000 as `write`. This PR does this for `forc
test` and our `e2e test suite`.
Each test in `forc test` will capture these calls and only print to the
terminal when requested with the `--log` flag.
## Garbage Collector and auto generated
Before, we were associating all auto-generated code with a pseudo file
called "<autogenerated>.sw" that was never garbage collected.
This generated a problem inside the LSP when the `auto_impl.rs` ran a
second time because of a collision in the "shareable type" map. When we
try to solve this collision, choosing to keep the old value or to insert
the new, the type inside the map points to already collected types and
the compiler panics. This is a known problem.
The workaround for this is to break the auto-generated code into
multiple files. Now they are named "main.autogenerated.sw", for example.
We create one pseudo-file for each real file that needs one.
When we garbage collect one file, `main.sw`, for example, we also
collect its associated auto-generated file.
## Checklist
- [ ] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
This PR refines trait coherence checking to guarantee that there is only
one valid implementation for each trait. It introduces improved orphan
rules and more rigorous overlap checks to prevent conflicting trait
implementations. With these changes, the system now more reliably
enforces coherence, ensuring that traits are implemented uniquely, and
reducing potential ambiguities.
This approach mirrors Rust’s design by enforcing two distinct safety and
coherence checks on trait implementations:
**1. Orphan Rules Check**
The orphan rules require that for any trait implementation, either the
trait or the type must be defined within the current package. This
restriction prevents external packages from implementing foreign traits
for foreign types, which could otherwise lead to conflicting
implementations and ambiguities across different parts of a codebase.
Essentially, it helps maintain clear ownership and boundaries of trait
implementations.
**2. Overlap Impl Check**
The overlap impl check ensures that no two trait implementations can
apply to the same type in an ambiguous manner. If two implementations
could potentially match the same type, it would be unclear which one
should be used, leading to coherence issues. By enforcing that
implementations do not overlap, the system guarantees that trait
resolution is unambiguous and predictable.
Together, these checks promote a robust and maintainable system by
ensuring that trait implementations are both locally controlled (orphan
rules) and non-conflicting (overlap check).
The test suite has been updated to comply with the new rules. However,
there is one current limitation regarding arrays. For arrays, the
coherence checks have been relaxed to avoid the need for numerous
concrete implementations in the standard library for traits like `Eq`
and `PartialEq`. This decision was made because support for const
generics is expected soon, which will allow these traits to be
implemented more cleanly.
Closes issue https://github.com/FuelLabs/sway/issues/5892.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
This PR adds `#[error_type]` and `#[error]` attributes to the collection
of known attributes, as defined in the [ABI Errors
RFC](https://github.com/FuelLabs/sway-rfcs/blob/master/rfcs/0014-abi-errors.md).
Additionally, the PR updates the outdated documentation for _Attributes_
and _Keywords_.
Partially addresses #6765.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
This PR removes the constraint on `u256` literals being only expressed
in hexadecimal.
The constraint has been removed and the code slightly refactored to
remove the unnecessary `radix` variable in the `lex_int_lit` function in
`token.rs`.
The corresponding error `LexErrorKind::U256NotInHex` has been removed
from the codebasen as well as the `should_fail` test looking to raise
this error.
The u256 testing suite has been augmented with additional tests to make
sure we can express u256 literals in decimal, binary and octal.
Closes#5456
## 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>
## 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.
## 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.
## Description
Merges the two libraries. They were initially separate to separate the
core logic and fuel vm specific functionality, but that separation is no
longer maintained so having a merged library is better.
Closes#6708
## Checklist
- [ ] I have linked to any relevant issues.
- [ ] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [ ] I have requested a review from the relevant team or maintainers.
---------
Co-authored-by: Sophie <47993817+sdankel@users.noreply.github.com>
Co-authored-by: Igor Rončević <ironcev@hotmail.com>
## Description
Fixes#6329 .
During insertion of `impl`s into the trait map we used to forget to
check for alias types, which meant that it was possible to have multiple
implementations of a trait for the same type, one for the original type
and one for the alias.
#6626 fixed this bug, but the error message was unhelpful in that it
reported the error on the original type without mentioning the alias.
This PR improves the error message, and also improves the error message
for aliased types when they contain multiple declarations of the same
member.
## 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>
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## 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>
## 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.
## Description
In contract_helpers.rs, replaced the ContractIdConstantNotAConstDecl
error with an Internal compiler error since this represents an
impossible state that should never occur in normal operation.
In error.rs, removed the now unused ContractIdConstantNotAConstDecl
error variant and its corresponding span implementation.
The changes make sense because:
The error was only used in one place where it represented an impossible
state
If that state is ever reached, it indicates a bug in the compiler itself
rather than user error
Using an internal compiler error will make it clearer that this is a
compiler bug that needs to be fixed if it ever occurs
fix#6841
## 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: IGI-111 <igi-111@protonmail.com>
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
Co-authored-by: jjcnn <38888011+jjcnn@users.noreply.github.com>
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
Fixes#6334 .
When compiling a contract call using v0 encoding the compiled code uses
a 4 byte function selector to determine which method is to be called.
This means that all methods in a contract must have distinct function
selectors to ensure that the wrong method isn't called by accident.
We have so far not had a check for distinctness of function selectors.
This PR introduces such a check.
Ideally the check should be performed on the ABI declaration rather than
on the contract, but since the method `to_function_selector_value` is
not implemented for trait methods (which are used to represent ABI
methods) I have opted to perform the check on contract declarations
instead. It would probably be possible to implement
`to_functiion_selector_value` on trait methods, but since we are in the
process of switching to v1 encoding it didn't seem worth it to spend
time on that.
This change may cause existing contracts to no longer compile, but in
those cases the contract's ABI declaration is unsafe, so I do not
consider this to be a breaking change.
## 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.
## 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.
## Description
Today, contract call uses the method name to identify which contract
method to call. That means that a contract cannot have multiple methods
with the same name.
That can happen when a contract implements traits:
A lot of the lifetime changes were caused by clippy.
## Checklist
- [ ] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [ ] I have requested a review from the relevant team or maintainers.
---------
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
[Fix handling of initialized associated constants in ABIs and
traits.](88fee13a14)
[Fix impl trait associated constant reference wrongly resolving to the
ABI
value](3a401f659d)
Fixes https://github.com/FuelLabs/sway/issues/6343 and
https://github.com/FuelLabs/sway/issues/6310.
## 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: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
This PR extends Serde support across all AstNode-related types, building
upon the partial implementation from #4193. Key points:
* Adds both `Serialize` and `Deserialize` trait implementations to all
relevant types.
* Prepares for upcoming language server features that will
serialize/deserialize types between keystrokes.
* Important: The type interface in the compiler is not yet stable. This
implementation is intended for temporary serialization/deserialization
work, not for persistent storage.
## Checklist
- [x] I have linked to any relevant issues.
- [ ] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
With this PR we no longer support using `self` instead of `Self` when
referring to the Self Type.
Fixes#6396
## 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.
## 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>
## Description
This PR implements the `__transmute` intrinsic. As Rust this intrinsic
should be a no-op semantically equal to a pointer cast. Although this PR
does not aim that it is 100% no-op yet.
At the moment some trade-offs were taken:
1 - References, pointers etc... are not allowed at the moment;
2 - `u16` and `u32` actually occupy 64bits. To allow transmute to work
in complex aggregates, this PR is accepting them as `u64`. Doing
otherwise would forbid `__transmute` to be no-op. Specially in complex
aggregates;
## Checklist
- [ ] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [ ] I have requested a review from the relevant team or maintainers.
---------
Co-authored-by: João Matos <joao@tritao.eu>
## Description
When find_method_for_type could not match the parameters and return type
with the available methods it would return the first match by name.
This was not a deterministic and secure behavior so now we strictly
match the parameter and return types.
Fixes#5086
find_method_for_type now if we have: impl<T> FromBytes for T
and: impl FromBytes for DataPoint, we pick the second implementation.
Fixes https://github.com/FuelLabs/sway/issues/6572
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
---------
Co-authored-by: IGI-111 <igi-111@protonmail.com>
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## 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
When we have a type annotation with placeholders and we assign to it the
result of a trait implementation call, if there is a single possible
trait implementation we can use its type in the type annotation type.
Fixes#5299
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
---------
Co-authored-by: IGI-111 <igi-111@protonmail.com>
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
For #6179, PR #6501 kept bumping into errors as it was doing too many
things, so I've split that PR into multiple PRs. This is the first, and
the only thing it does is move all of the various `Cargo.toml`
dependencies into the single workspace `Cargo.toml`.
Future PRs will:
- Update dependency versions
- Update code that breaks from the version bumps
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
We now throw an error that enforces cfg arg to be a valid one.
Fixes#6326
## 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.
## Description
This PR adds support for FuelVM `wqxx` instructions in ASM blocks. Some
of those instructions were up to now partially supported in IR and ASM
generation but not in ASM blocks. The immediate motivation for adding
support for these instructions is the need for `wqml` instruction in the
new implementation of `u256::pow()`.
Additionally, the PR adds expressive diagnostics for
`UnrecognizedOpCode` parsing error.
## Checklist
- [ ] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
To be merged after https://github.com/FuelLabs/sway/pull/6250
## Checklist
- [ ] I have linked to any relevant issues.
- [ ] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [ ] I have requested a review from the relevant team or maintainers.
---------
Co-authored-by: Brandon Kite <brandonkite92@gmail.com>
Co-authored-by: IGI-111 <igi-111@protonmail.com>
## Description
This PR fixes#6320 and #6431 by:
- properly treating the `scwq` instruction in purity check as a storage
writing instruction.
- not emitting purity issues for `__entry` functions.
Additionally, the PR:
- removes purity checks from the type-checking phase. Those checks were:
- redundant. The same checks were also done at the IR side.
- incomplete. The checks were covering only the function and method
calls, not other kinds of storage access (e.g., intrinsics).
- inaccurate. The checks were relying on `#[storage]` attributes, which
do not necessary represent actual storage access patterns.
- extends `MetadataManager` to be able to store more then one `Span` per
`MetadataIndex`. E.g., for a function, we can now store the span of the
whole function declaration, but in addition, also the span pointing only
to the function name.
- removes two different and overlapping storage access mismatch errors
and introduces one expressive diagnostics that points to the exact
storage access violations inside of a function (see demo below).
Note that having the purity tests at the IR level means that no purity
errors will be reported on non-used functions. This was already the case
before, since the complete set of tests was done at the IR level, and
only two tests (inaccurately) at the type-checking phase, where errors
would be reported even for the non-used functions. The purity guaranty
is given for all the compiled code.
Closes#6320.
Closes#6431.
## Demo
Before, we had two different error messages, rendered potentially
several times per access violation.
Now, we have only one error message that points to the access violations
and explains them.
## 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.
## Description
Fix https://github.com/FuelLabs/sway/issues/6342 and
https://github.com/FuelLabs/sway/issues/6370.
https://github.com/FuelLabs/sway/issues/6342 occurs because when the
type checker unifies `Numeric` with an unsigned integer, it never checks
if the original literal actually fits into the new "unified" type.
https://github.com/FuelLabs/sway/issues/6370 happens because we never go
back to the array and check if every item actually is valid.
This PR is now doing these two tests at `type_check_analyze`.
## Checklist
- [ ] I have linked to any relevant issues.
- [ ] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [ ] I have requested a review from the relevant team or maintainers.
---------
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## 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 fixes#6332 and #6354 by:
- including number of instructions in ASM blocks when calculating
overall number of instructions for function inlining.
- properly lowering ASM blocks that return unit, `()`, without return
register to returning `$zero` in the ASM.
Additionally, the PR:
- removes dead ASM blocks (that do not have side-effects) in the DCE
pass.
- prints ASM blocks that return `()` without a register as `-> ()` to
make it consistent with functions.
- emits a warning if an ASM block is empty.
- adds expressive diagnostic for `UninitializedAsmRegShadowsItem`
warning and extends the warning for constants and configurables.
- removes obsolete `NamespaceAttributeDeprecated` warning and its empty
tests.
- harmonizes and defines guidelines for ASM instruction comments.
Closes#6332.
Closes#6354.
## Bytecode size changes
Changes in the `fn-inline` and `dce` optimizations had a minimal impact
on the bytcode sizes of the `should_pass` test programs. Out of 455
tests, only 13 tests changed sizes. 8 tests got a size increase of 0.8%
in average, while 5 tests got size decrease of 3.0% in average.
The real-world
[compolabs-orderbook](https://github.com/compolabs/orderbook-contract)
contract got a minimal size decrease of 0.16%.
<details>
<summary>Click here for the numbers</summary>
Test | Before | After | Decrease | Percentage
-- | -- | -- | -- | --
empty_fields_in_storage_struct | 28384 | 28456 | -72 | -0.25
language/deprecated_attribute | 224 | 208 | 16 | 7.14
language/duplicated_storage_keys | 224 | 208 | 16 | 7.14
language/references/dereferencing_operator_dot_on_structs | 124920 |
125272 | -352 | -0.28
language/references/dereferencing_operator_dot_on_tuples | 124920 |
125272 | -352 | -0.28
language/references/dereferencing_operator_index | 92376 | 92344 | 32 |
0.03
language/references/dereferencing_operator_star | 151152 | 151536 | -384
| -0.25
language/references/impl_reference_types | 7840 | 7776 | 64 | 0.81
language/references/reassigning_via_references_passed_and_returned_to_and_from_functions
| 39008 | 39184 | -176 | -0.45
language/references/reassigning_via_references_to_expressions | 36920 |
37064 | -144 | -0.39
language/references/reassigning_via_references_to_values | 13952 | 13936
| 16 | 0.11
stdlib/storage_vec_insert | 8480 | 8552 | -72 | -0.85
stdlib/vec_byte_remove | 1904 | 1976 | -72 | -3.78
</details>
## 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.
## Description
Fixes#6378
## 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: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
## Description
This PR is part of https://github.com/FuelLabs/sway/issues/5110 and
introduces two new intrinsic: `__slice` and `__elem_at`.
`__slice` allows the creation of slices by slicing arrays or other
slices. Whilst `__elem_at` returns a reference to an item inside the
slice or the array.
## Out of bounds checks
These intrinsic will not generate any runtime checks, these must be done
manually, when and where appropriate; but they do a complete static
analysis of all indices, to avoid runtime buffer overflows, when
possible.
That means that at runtime, it is possible to do a buffer overflow when
reading/writing, which is an "undefined behaviour" as to what will
happen.
## Empty Array
This PR also solves a problem with empty arrays. Before empty arrays
such as `let a = []` were being type-checked as `[Never; 0]`, which
means that any code after them was being marked as dead.
Now we correctly type check them as `[Unknown; 0]` and return a more
friendly error.
```
4 |
5 | // Empty array
6 | let a = [];
| ^^ Type must be known at this point
7 | }
|
____
```
## Check of constants inside fns
This PR also solves a problem with not checking `const` expressions
inside `fns`. We, for example, do not allow slices in constants, but we
were only checking globals. Now we check constants also inside
functions, methods etc...
## Small improvements for our e2e
We can now `dbg` inside our e2e harness and get results like the ones
below. One needs to include the lib `test/src/e2e_vm_tests/utils` and
cal `something.dbg()` or `something.dbgln()`. There is no magic, and
structs/enums will need to manually implement the `Dbg` trait.
This is only to facilitate the debugging of our e2e tests.
## 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.
## Description
This PR strengthens existing and adds new tests for associated
constants. This extended test coverage revealed the following existing
issues: #6310, #6348, #6345, #6346, #6343, #6344.
It also pointed out that we are missing rules for a contract
implementing several ABIs with overlapping interface surfaces, where
constants can also be overlapping: #6306.
All the issues are linked to tests via TODOs in code that is commented
out. We will address the issues in separate PRs. With this PR, we want
to first have tests in place.
Additionally, the PR:
- cleans up dead code that become obsolete when `TyConfigurableDecl` was
introduced in #6058.
- deletes some redundant tests for constants.
- groups some tests to reduce test compilation and execution time and
provides guidelines for such groupings in the testing README.md.
## 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.
## Description
This PR:
- emits errors when configurables clash with global constants of the
same name
- forbids shadowing configurables with local constants or variables
- forbids matching against configurables in pattern matching
Before #6058, it was just the flag `is_configurable` in `TyConstantDecl`
that marked constants as configurables. The first two points were
implemented for `TyConstantDecl` and, thus, worked both for constants
and for configurables. When introducing `TyConfigurableDecl` we forgot
to extend those checks to cover the new type declaration.
The third point fixes a bug that allowed matching against configurables,
although they are not compile-time constants.
Originally, matching was done against the configured value, which was
treated as a constant, even if changed during the deployment.
After introducing `TyConfigurableDecl`, because of a bug, configurables
were treated as pattern variable declarations.
This PR brings back the original shadowing behavior and forbids matching
against configurables in pattern matching.
Forbidding configurables in pattern matching can cause confusion,
knowing that regular constants can be matched against. A special
consideration was given to explain to developers why this is the case.
## Breaking Changes
There were two releases in between. Theoretically but unlikely, it could
be that some code appeared that e.g., shadows configurables. In such a
case, the change in this PR will be breaking and cause compiler errors.
## Demo
## 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.
## Description
Optimization Explanation
- Using HashSet to track seen elements simplifies the code logic.
- Using the retain method directly filters out duplicate elements in
place, avoiding the complexity of manually managing indices and swapping
elements.
- The code is more concise and readable while maintaining the original
order.
- Time complexity comparison: Original code: Due to the need to manually
manage indices and swap elements, the time -complexity is O(n^2) (in the
worst case). Optimized code: Using HashSet and the retain method, the
time complexity is O(n).
- Space complexity comparison: Original code: Requires additional
HashMap and SmallVec to store hash values and indices. Optimized code:
Only requires a HashSet to store seen elements.
## 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.
---------
Co-authored-by: IGI-111 <igi-111@protonmail.com>
## Description
Fixes#3113 . Closes#2767 as Won't Fix, since one must use `pub use` to
reexport items.
This PR Introduce reexports through the use of `pub use`. The
implementation now keeps track of the visibility of a `use` statement,
and that visibility is in turn taken into account when items are
imported from the module where the `use` statement resides.
This feature allows `std::prelude` and `core::prelude` to be handled
correctly, instead of the special-case handling that we have been using
so far. The method `star_import_with_reexports` has therefore been
merged with `star_import`, and the `prelude.sw` files have accordingly
been changed to use `pub use` instead of `use`.
Note that `sway-lib-std/lib.sw` has a spurious import of `core::*`,
which has no effect, so I have removed that import.
This change also allows us to remove a hacky solution in
`lexical_scope.rs`. The hack was introduced because the special-case
handling of preludes meant that the preludes would contain multiple
copies of the same `std` and `core` items. Now that we no longer need to
treat the preludes specially, we can remove the hack.
I have gone a little overboard in adding tests, partly because I wanted
to make sure I hadn't missed some corner cases, but also because our
tests of the import logic has poor code coverage. I have found the
following issues that I don't think belongs in this PR, but which need
to be handled at some point:
- Path resolution is broken. The tests
`should_pass/language/reexport/simple_path_access` and
`should_fail/language/reexport/simple_path_access` are supposed to test
that you can access reexported using a path into the reexporting module,
i.e., without importing them using a `use` statement. Both tests are
disabled because path resolution is broken. I plan to fix that as part
of #5498 . A simlar problem exists in the test
`should_pass/language/reexport/reexport_paths` where an item is imported
via `std::prelude`.
- There is an issue with the import and reexport of enum variants, which
is illustrated in
`should_pass/language/reexport/reexport_paths_external_lib`. In short,
`pub use ext_3_lib::Items3_Variants::U` elevates the name `U` to the
top-level namespace in a module, and this makes `U` inaccessible as a
variant of `Items3_Variants`. I'm not sure how this is supposed to work,
but since it's related to all imports whether they are reexported or not
I have left it as a separate issue #6233 .
- Aliasing of enum variants (`use lib::Enum::X as MyX`) doesn't work
properly. In some cases `MyX` is available in the way you would expect,
and in other cases it is not, and sometimes it is available but not
recognized as being a variant of `lib::Enum`. The test
`should_pass/language/reexport/aliases` has a number of tests of these
types of things. #6123 tracks the issue.
- Aliased traits are not handled correctly by the dead code analysis.
The test `should_pass/language/reexport/aliases` generates warnings
about unimplemented traits that are actually implemented, but since they
are aliased in imports the DCA doesn't catch them. #6234 tracks the
issue.
Re. documentation: The whole import system is completely undocumented in
the Sway book, and I plan to write up a draft how it works when I'm done
fixing (the majority of) the many issue we have there. At the very least
I'd like to postpone the documentation efforts until path resolution
works correctly, since that is key to how the import system works.
## 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>
Co-authored-by: João Matos <joao@tritao.eu>
## Description
This PR closes https://github.com/FuelLabs/sway/issues/6118.
If for some reason an older `core` ends up being used, we now warn with
a more user-friendly error.
```
error: Configurables need a function named "abi_decode_in_place" to be in scope.
--> /home/xunilrj/github/sway/test/src/e2e_vm_tests/test_programs/should_pass/language/configurable_consts/src/main.sw:42:5
|
...
42 | ARRAY_BOOL: [bool; 3] = [true, false, true],
| ^^^^^^^^^^
|
= help: Certify you are accessing a compatible version of the "core" library.
____
```
We also use a better span when warning about unused configurables.
```
warning
--> /home/xunilrj/github/sway/test/src/e2e_vm_tests/test_programs/should_pass/language/configurable_consts/src/main.sw:47:5
|
45 |
46 |
47 | NOT_USED: u8 = 1,
| -------- This declaration is never used.
48 | #[allow(dead_code)]
49 | NOT_USED_BUT_ALLOWED: u8 = 2,
|
____
Compiled script "configurable_consts" with 1 warning.
```
## 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: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
Co-authored-by: Igor Rončević <ironcev@hotmail.com>
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
