## Description
Continuation of https://github.com/FuelLabs/sway/pull/7044.
This PR converts `TypeArgument` to an enum to support "const generic" in
the future. It is being done separately because it changes a lot of
files.
No change in behaviour is expected.
## 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.
## Description
This PR only brings type and const generic arguments to the same `Vec`.
It is being done separately because it changes a lot of files.
No change in behaviour is expected.
## 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.
## Description
This PR is part of https://github.com/FuelLabs/sway/issues/6860.
It continues the implementation of more `std` library "traits" for
arrays.
It also fixes a small error when formatting "const generics
declarations".
## 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 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
Fixes#6846 .
The dependency graph is currently represented as a tree structure in the
field `Root::external_packages` field. Since the dependency graph is in
general a dag, there is a potential exponential blowup in representing
it as a tree structure, so we would like to instead represent it using a
linear structure.
In order to create a linear structure we will need to move the
dependency graph out of the `Root` struct, so that `Root` objects can be
inserted into the dependency graph without causing issues with Rust.
This PR is a step towards that goal in that moves almost all the code
that accesses `external_packages` from `impl Root` to `impl Namespace`.
In particular:
- The functions that perform imports have been moved. This also allows
some minor simplifications of the code, since imports are only ever
performed with the destination being the current module.
- The module visibility check has been moved, and simplified.
- Various helper functions have been moved, and simplified.
- `module_mut_from_absolute_path` has been moved, and mutable access to
external modules has been eliminated.
`module_from_absolute_path` has not yet been moved, since this function
is used by `sway-lsp`, which does not have access to a `Namespace`
object. This will be fixed as part of the datastructure change.
Additionally, a few other refactorings have taken place:
- The `ResolvedDeclaration` type has been moved to its own file.
- `Root` has been renamed to `Package`, with variables and fields
renamed accordingly.
## 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
Implements dereferencing as LHS in reassignments for projections.
With this PR we will support:
- `(*array)[0] = 1`
- `(*tuple).0 = 1`
- `(*struct).a = 1`
This also includes support for nested references.
Fixes#6397
There is some progress in #5063
## 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
Fixes#6119 .
Currently, items implicitly imported from the standard library preludes
reside in the same namespace as star imports from non-prelude sources.
This means that if a star import imports a name that clashes with a name
from a prelude, then using that name in the importing module causes an
error.
This PR separates the prelude imports into a different namespace, and
allows star imports to shadow prelude imports.
## 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>
## Description
This is part of https://github.com/FuelLabs/sway/issues/6860.
This completes abi encoding for arrays. Allowing arrays of any size as
inputs and outputs in predicates/scripts/contracts.
This PR also allows arrays to be initialized with "const generics" such
as:
```sway
#[cfg(experimental_const_generics = true)]
impl<T, const N: u64> AbiDecode for [T; N]
where
T: AbiDecode,
{
fn abi_decode(ref mut buffer: BufferReader) -> [T; N] {
let first: T = buffer.decode::<T>();
let mut array = [first; N]; // <-------------------- This can used now
...
array
}
}
````
## 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 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
A couple PRs with trait map optimizations developed as part of trait
coherence effort.
## 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
When running tests in contracts with the fallback function, we get an
error with the `__log` intrinsic. The issue is that we needlessly
compile the fallback function twice. And in some cases (numeric decay),
the `__log` argument would return a `TypeId` that was not collected in
the `collect_metadata` phase.
```
29 |
30 | use std::call_frames::*;
31 | __log(3);
| ^^^^^^^^ Internal compiler error: Unable to determine ID for log instance.
Please file an issue on the repository and include the code that triggered this error.
32 | __log(called_method());
33 | __log("double_value");
|
____
```
This was never caught because we only compile `sdk-harness` tests, we
never run their unit tests in the CI. Which this PR is also doing.
## Checklist
- [ ] I have linked to any relevant issues.
- [ ] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
This PR:
- extends infrastructure for writing migrations that modify individual
expressions and do not need access to a broader scope. It does that by
providing lexed and typed tree visitors. Visiting lexed and typed tree
is implemented to the level needed to write the migration for `impl
TryFrom<Bytes> for b256`.
- implements the migration for `impl TryFrom<Bytes> for b256` as
explained in #6994.
Adding `#[cfg(experimental_try_from_bytes_for_b256 = true)]` to the
`impl TryFrom<Bytes> for b256` revealed that there existed already an
`impl TryFrom<Bytes> for b256` in `std::primitive_conversions::b256`.
Due the lack of trait coherence there was no any errors when it was
re-implemented in `std::bytes`.
This PR marks the existing impl in `std::primitive_conversions::b256`
with `#[cfg(experimental_try_from_bytes_for_b256 = false)]` so that it
will be removed in the next breaking release, in favor of the new impl
in `std::bytes`.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
Updates trait map to track fully resolved impl type parameters.
To be used for trait coherence checking.
## 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: Joshua Batty <joshpbatty@gmail.com>
## Description
This PR is part of https://github.com/FuelLabs/sway/issues/6860.
It implements "impl traits" for "const generics", which means syntax
such as:
```sway
trait A {
fn my_len(self) -> u64;
}
impl<T, const N: u64> A for [T; N] {
fn my_len(self) -> u64 {
N
}
}
```
This also opens the space for simplifying our current implementation of
`AbiEncode` for arrays. Today we implement for each size, which limits
us to a specific size. With this one can have just one "impl item", and
support arrays of arbitrary size.
Both implementations will coexist in `codec.sw` until we stabilize
"const generics".
```sway
#[cfg(experimental_const_generics = true)]
impl<T, const N: u64> AbiEncode for [T; N]
where
T: AbiEncode,
{
fn abi_encode(self, buffer: Buffer) -> Buffer {
....
}
}
#[cfg(experimental_const_generics = false)]
impl<T> AbiEncode for [T; 0]
where
T: AbiEncode,
{
fn abi_encode(self, buffer: Buffer) -> Buffer {
...
}
}
```
## 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
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
## 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
## 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
Fully resolves trait constraints call paths. To be used in trait
coherence work.
## 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 is part of https://github.com/FuelLabs/sway/issues/5110. It
fixes a problem that improves the usability of slices.
When a method is returned from the "method resolution algorithm", if any
generic is involved, it is returned as its generic form. So for example,
if a method `len` is called on `Vec<u8>`, we return something like `fn
len(self: Vec<T>)`.
Later we monomorphize `T` into `u8`. To do that we run a "pattern match"
to realize that we need to replace `T` with `u8`.
In this case, the bug was that we were not considering that some
primitive types have "implicit type parameters".
This was found whilst creating more tests for
https://github.com/FuelLabs/sway/pull/6933, because I was not able to
call the `len` method defined for slices as:
```sway
impl<T> &[T] {
pub fn len(self) -> u64 {
...
}
}
```
## 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
Moves dev dependencies to the workspace Cargo.toml for consistent
versions in tests.
Inspired by https://github.com/FuelLabs/sway/pull/6955
## 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 allows `LDC` opcode in predicates. Historically, it was not
allowed in the FuelVM, but this restriction is removed and we are
removing it now from Sway as well.
## Checklist
- [ ] I have linked to any relevant issues.
- [ ] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
The `bldd` opcode was not covered in the `Op::parse_opcode()` which
resulted in `Unknown opcode: "bldd"` error.
The remaining part of the `bldd` opcode integration chain is already
implemented in #6254.
## 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
Add support for the `#[deprecated]` attribute to functions, enums,
struct items, enum variants and propagate deprecation check exhaustively
throughout expressions variants.
Partially addresses #6942.
Support for deprecating traits, abis and the methods thereof in their
definitions is still missing, as well as scrutinees and storage fields.
## 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
The ECAL opcode is supported in `fuel-vm` to extend the capabilities of
the VM.
Users can implement rust code to interop with the VM using the ECAL
opcode.
This PR introduces support for the opcode in the sway repo - such that
sway assembly can be successfully compiled with the ECAL opcode.
Examples of how to utilize the `ECAL` opcode can be seen here:
9478991db1/fuel-vm/examples/external.rs (L51)
- Closes https://github.com/FuelLabs/sway/issues/5239
- Added an e2e test to validate compilation of ecall opcode in sway
assembly.
## 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.
- [ ] 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: z <zees-dev@users.noreply.github.com>
## Description
This PR solves an issue with `__transmute` in "const contexts". In these
cases, the "source" and "return" types were not being correctly solved.
## 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.
---------
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
Fixes#6391.
This PR fixes an issue with variable declarations whose initializers
diverge because they contain `return`, `continue` or `break`
expressions. In this case the initializer typechecks to `Never`, and the
variable is inferred to have type `Never` in the subsequent
(unreachable) code:
```
let mut x = return;
x = 42; // Illegal, since x has type Never
```
The problem is that this is the case even when the variable declaration
has a type ascription:
```
let mut x : u32 = return;
x = 42; // Should be legal, since x has the type ascription u32
```
As part of the fix there is another slight change of behavior for code
blocks that diverge. Until now the type of a code block has been
determined based on whether it contains a diverging expression:
```
match { return; true } // Considered to have type Never because of `return;`
{
// Type Never does not have a constructor
}
```
We now determine the type of a code block based on its implicit return:
```
match { return; true }
{
// Type Boolean has two constructors
true => ...,
false => ...,
}
```
In principle this is a breaking change, but the only change in behavior
is in code blocks that contain a `return`, `break` or `continue`, and
then contains dead code after that expression, so I can't imagine anyone
will be affected by it.
## 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: IGI-111 <igi-111@protonmail.com>
## Description
Some use cases require the compiler to call
insert_implementation_for_type on every call of find_method_for_type.
This would double the compile time of a simple script. To avoid this we
removed the TraitMap::insert_for_type. The TraitMap now only stores the
original implementations and uses a less restrictive unify_check to get
those that match the concrete implementations.
This significantly reduces the TraitMap's size and speeds up the lookup
times. On the other hand, it also introduces a type substitution on
every find_method_for_type.
A future PR will address the performance of doing type substitutions.
Fixes#5002.
Fixes#6858
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [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
unify_structs was also unifying the fields and unify_enums was also
unifying the variants.
This was removed because comparing call paths and type parameters is
enough.
Fixes#6394
## 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.
Signed-off-by: Marcos Henrich <marcoshenrich@gmail.com>
## Description
This PR:
- implements partial equivalence in the `core::ops`, as explained in
detail in #6883. The implementation is opt-in and behind the
`partial_eq` experimental feature flag.
- implements `forc migrate` migration steps for automatic migration to
`partial_eq` feature.
- extends the infrastructure for writing `forc migrate` migrations.
- preserves `Annotation`s on `LexedModule`s in the `LexedProgram`.
(Those were before stripped off and not available in the compiled
`Programs`. This resulted in loss off `//!` doc-comments that are
represented as `doc-comment` annotations.)
Extensions in the `forc migrate` infrastructure include:
- possibility to postpone migration steps. This allows writing
multi-step migrations where the first step is usually early adopting an
experimental feature by using `cfg` attributes in code. This possibility
is crucial for migrating our own codebase where we want to early-adopt
and test and stabilize experimental features.
- possibility to match elements on both mutable and immutable parsed
trees. The initial assumption that immutable matching on typed trees
will always be sufficient does not hold. Experimental `cfg` attributes
can remove parts of typed trees that might be needed in analysis.
- `LexedLocate(As)Annotated` for easier location and retrieval of
`Annotated` elements.
- additional implementations of existing traits.
- additional `Modifier`s for modifying existing elements in the lexed
tree.
- `New` struct for convenient creation of often needed lexed tree
elements. Note that we do not expect migrations to generate large new
parts of lexed trees, but mostly to modify or copy and modify existing
ones.
Almost all of the changes in the Sway files are done automatically by
the migration steps. The only manual change was in the `core` library
(`std` library is also automatically migrated) and in slight extension
of two of the tests.
Note that some of the tests have `Eq` traits in trait constraints. As
explained in the #6883, it is not necessary to change those to
`PartialEq`. We might consider changing some of them, for testing
purposes, and such a change is done on one of the tests that was testing
the behavior of the `Eq` trait. But for the majority of the tests, there
is no strict need for switching from `Eq` to `PartialEq`.
Rolling `PartialEq` out in the tests provoked three existing issues that
will be fixed in separate PRs: #6897, #6898, #6899.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
This PR is part of https://github.com/FuelLabs/sway/issues/6860.
In future PRs, we will need a way to declare array lengths that are not
literals.
This PR enables this by postponing the length resolution to the
`type-check` phase.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
---------
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
`type_check_method_application` does the parsing of arguments in 2
passes, but when the `resolved_method_name` failed the argument error
would not be displayed.
We now store the arg_handlers and append their errors in case
`resolve_method_name` fails.
Fixes#5660
## 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).
- [ ] I have requested a review from the relevant team or maintainers.
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [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 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
Updated the `fuels-rs` SDK to `0.77`.
This required updating transitive dependencies to the relevant versions
specified in fuels-rs sdk.
## Dependency tree
```mermaid
graph TD
sway[sway]
fuelsrs[fuels-rs]
fuelabi[fuel-abi-types]
fuelvm[fuel-vm]
forcwallet[forc-wallet]
fcoreclient[fuels-core]
fvmprivate[fuel-vm-private]
%% Main dependency relationships
sway --> fuelsrs
fuelsrs --> fuelabi
fuelsrs --> fuelvm
fuelsrs --> forcwallet
fuelsrs --> fcoreclient
%% Secondary dependencies
fcoreclient --> fvmprivate
fvmprivate --> fuelvm
%% forc-wallet dependencies
forcwallet --> fuelvm
forcwallet --> fuelsrs
%% Styling
classDef primary fill:#d0e1f9,stroke:#4a90e2,stroke-width:2px
classDef secondary fill:#e8f4ea,stroke:#66b366,stroke-width:2px
class sway,fuelsrs primary
class fuelabi,fuelvm,forcwallet,fcoreclient,fvmprivate secondary
%% Add notes
subgraph Note
note[Update forc-wallet first due to circular dependency]
style note fill:#fff4e6,stroke:#ffab40,stroke-width:1px
end
```
## 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: z <zees-dev@users.noreply.github.com>
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
Co-authored-by: hal3e <git@hal3e.io>
## Description
The unify_checker was returning false when comparing `MyOption<T>` with
`T`. And filter_by_type_inner type substitution when adding methods from
`MyOption<T>` to `MyOption<MyOption<T>>` was replacing MyOption<T> in
its own type, ending up by inserting into type
`MyOption<MyOption<MyOption<T>>>` instead of `MyOption<MyOption<T>>`.
Fixes#6825
## 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: Joshua Batty <joshpbatty@gmail.com>
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
## Description
DWARF debug symbols are now automatically generated and saved as
`debug_symbols.obj` in the output directory when using debug builds.
This enables better debugging support out of the box in development
without requiring the `-g` flag. The `-g` flag is still supported for
specifying custom debug symbol output paths or generating debug symbols
in other build profiles.
## Checklist
- [ ] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [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.
