## Description
Fixes#5498.
This PR contains a major refactoring of the namespace module, which is
responsible for keeping track of the symbol bindings in the program. The
refactoring is intended to reduce memory allocation during compilation,
and also fixes a number of minor bugs related to path resolution.
### Advice to the reviewer:
I recommend reviewing this PR in 3 steps:
1. Review the PR description. If something in the description is
unclear, then leave a review comment, and I will try to address the
issue. The code changes will be significantly easier to review once you
get the overall idea of what is happening.
2. Review the files `sway-core/src/semantic_analysis/namespace/root.rs`,
`sway-core/src/semantic_analysis/namespace/namespace.rs` and
`sway-core/src/language/call_path.rs`. These files contain the major
datastructure changes, and if anything in those files needs to be
addressed, then there is limited value in reviewing the rest of the code
changes.
3. Review the remaining files. These code changes are all consequences
of the changes in step 2, so it shouldn't take too much time, even
though there are quite a few changes.
### Remaining issues
No remaining issues except for what reviwers bring up.
### Breaking changes
As illustrated by one of the test cases the PR makes paths to external
libraries such as `::core::codec::*` illegal. This is a bugfix rather
than a change in behavior (the correct path is `core::codec::*`), but
may require updates of existing programs.
Additionally, the visibility check for modules was broken, so some
modules declared using `mod x` would have incorrectly been considered
public even though it should have been declared `pub mod x`. Again, this
is a bugfix rather than a change of behavior, but may require updates of
existing programs.
### Changes made by this PR
_Representation of the dependency graph_ (main file:
`sway-core/src/semantic_analysis/namespace/root.rs`)
Previous: External libraries were represented as submodules of every
module in the program. This meant that every module in every external
package was cloned for every module in the program, and recursively so,
since external libraries could also have dependencies that required
clones for every module. In particular, `std` has `core` as a
dependency:
```
core:
"" (lib.sw)
/ / | \ \
primitives raw_ptr raw_slice slice ...
std:
"" (lib.sw)
/ / | \ \
core constants vec primitive_conversions ...
/ / | \ \ | | | | \
... core core core b256 ...
/ / | \ \ / / | \ \ / / | \ \ |
... ... ... core
/ / | \ \
...
External library:
"" (lib.sw)
/ / | \
core std submodule ...
/ / | \ \ / \ / \ \
... core ... core std ...
/ / | \ \ / / | \ \ / \
... ... core ...
/ / | \ \
Main program:
"" (main.sw)
/ / | \
core std external library submodule
/ / | \ \ / \ / \ \ / | \
... core ... core std submodule core std external library
/ / | \ \ / / | \ \ / \ / \ / \ / \ / | \
... ... core ... ... ... ... core ... core std ...
/ / | \ \ / \ / \ / \
... ... core ...
/ \
...
```
Changes in this PR: External libraries are now represented only at the
package root. The root module is given the same name as the package so
that paths beginning with the package name can be resolved as a module
path. If multiple libraries depend on the same external library, then
they each contain a clone (this can be resolved a at later stage by
introducing a global table of libraries).
```
core:
core (lib.sw)
/ / | \ \
primitives raw_ptr raw_slice slice ...
std:
std (lib.sw) ====== externals =====> core
/ / | \ \
/ | | \ ...
constants vec primitive_conversions ...
/ \
b256 ...
External library:
external_lib (lib.sw) === externals ===> core
/ \ / / | \ \
submodule ... ...
|
... std == externals => core
/ / | \ \ / / | \ \
... ...
Main program:
main_program (main.sw) === externals ===> core
/ \ / / | \ \
submodule ... ...
|
... std == externals => core
/ / | \ \ / / | \ \
... ...
extenral_lib == externals => core
/ / | \ \ / / | \ \
... ...
std == externals => core
/ / | \ \ / / | \ \
... ...
```
Reasoning: This change dramatically reduces the amount of cloning of
external libraries. The cloning is not eliminated completely, since
multiple libraries may have the same library as a dependency (e.g.,
`core` is used as a dependency for both the program and `std`, so if the
program depends on `std`, then there will be two clones of `core` in the
tree). The remaining cloning can be eliminated by introducing a global
table of libraries, which should be doable without making significant
changes to the path resolution algorithm.
_Callpath representation_ (main file:
sway-core/src/language/call_path.rs)
Previous: Paths to externals were considered relative to current module.
This worked because all externals existed a submodules of every module.
Paths inside the current package were ambiguous, and were either
interpreted relative to current module or relative to the root module.
The root module did not have a name, so the empty path was used to
indicate the root module.
Now: All full paths start with the name of the package, which is also
the name of the root module. If the first identifier is not the name of
the current package, then we look in the externals of that package, and
if the name isn't found there we throw an error. Note that the name of
an external is defined in Forc.toml, and may be different from the name
used inside the external library (e.g., a library may call itself `X`,
but a project may use `X` as an external under the name `Y`). This means
that any path that escapes from a library must have its package name
changed.
Reasoning: This is all a conseqence of the change to the representation
of the dependency graph. We need to be able to the rely on the package
name in order to resolve the path within the correct pacakge.
Additionally, if a path escapes from a dependency to a dependent, then
the package name must be changed to what the package is called in the
dependent.
_CallPath.callpath_type_ (main file:
sway-core/src/language/call_path.rs)
Previous: The CallPath struct contained a flag `is_absolute`, which, if
set, was used to mean two different things. For parsed paths it was used
to signal that the path started with `::`, i.e., that the path should be
resolved relative to the current package root. For paths generated
during typechecking the flag was used to indicate that the path was a
full path, i.e., that it should either be resolved relative to the
current package root or that it was a path to an external library.
Now: `is_absolute` has been replaced with `callpath_type`, which has 3
possible values: `RelativeToPackageRoot`, which indicates that the path
started with `::`, `Full`, which indicates that the path starts with the
package name, and `Ambiguous`, which indicates that the path should
either be resolved relative to the current module, or that it is a full
path referring to an external library.
Reasoning: A path has 3 different states, so a boolean flag is not
sufficient to represent all states.
_Path representation_ (main file: sway-core/src/language/call_path.rs)
Previous: Full paths always pointed to the module containing the
declaration of the thing that the path resolves to.
Now: Full paths point to a module where the suffix is bound. This may
not be the module containing the declaration of the thing the suffix is
bound to, because the binding may be the result of an import. The trait
map is special in that the path to the actual declaration is used as a
key in the map, so for traits we use the canonical path, which point to
the module where the declaration resides.
Reasoning: The previous definition of full paths required a duplication
of the symbol resolution algorithm in order to construct the full path,
and it was getting very difficult to maintain. In the vast majority of
cases we only need the full path to indicate somewhere where the symbol
can be resolved, and don't actually need to know where the declaration
resides. In the few cases where we do need to know the path to the
declaration (the trait map uses these paths as keys) we can generate the
canonical path by first converting to the full path, and then resolving
the path and using the path stored with the binding in the lexical
scope, since this is the path to the actual declaration. Additionally,
the previous solution was only able to generate full paths for paths
where the suffix is an identifier - for other suffix types we could not
generate a full path. This has now been changed so that we can generate
full paths for all paths, although canonical paths are still restricted
to paths with an identifier as the suffix. This also moves us closer to
a situation where we can represent semantic (canonical) paths separately
from syntactic callpaths.
_Namespace.init removed_ (main file:
sway-core/src/semantic_analysis/namespace/namespace.rs)
Previous: The `Namespace` struct contained an `init` module which was
used as a template for new modules, a clone of which was created every
time the collection pass or the typechecker entered a submodule. This
template contained all external libraries as submodules, as well as (for
contract pacakges) a (new) declaration of `CONTRACT_ID`.
Now: The `init` module has been removed. When the collection pass or the
typechecker enters a new submodule, `Namespace` creates a new `Module`
(if none exists yet for the relevant submodule), and populates it with
implicit imports (`core::prelude::*` and `std::prelude::*`, and for
contract packages `CONTRACT_ID`).
Reasoning: The current solution makes it significantly clearer what is
in a new `Module` object. Additionally, the declaration of `CONTRACT_ID`
is no longer duplicated in each module - it is now declared once in the
root module, and imported everywhere else.
_namespace encapsulation_ (main file:
sway-core/src/semantic_analysis/namespace/namespace.rs)
Previous: The `Namespace` struct contained methods to extract the
underlying datastructures in the `namespace` module.
Now: An attempt has been made to encapsulate the `namespace` module a
little bit more, so that changes and lookups to the datastructures in
the `namespace` module are done by calling methods on the Namespace
struct rather than letting the caller extract the datastructures and
manipulating them directly.
Reasoning: When the datastructures are manipulated in many different
places it makes it very hard to track down all the places that need to
be changed when making changes to the datastructure. The current
solution is not perfect, but it does encapsulate things a bit better
than before.
### Minor changes and improvements
A few minor improvements have been made:
- A compilation unit (`core`, `std`, etc.) is now referred to as a
_package_. (Note: The `Root` struct should probably be renamed to
`Package` for consistency)
- The visibility check for path resolution in `type_resolve.rs` had to
be updated because path resolution was changed. The current version is
not perfect, but it does improve the faulty check we had before.
- `TyModule` so far contained a clone of the `Namespace` struct in the
state it was in when typechecking of the relevant module was done. The
`Namespace` object was never used except for the one in the root module,
so I have moved the `Namespace` clone to `TyProgram`, thus eliminating
quite a bit of unnecessary cloning (the Namespace struct owns the
current package `Root` object, and thus cloning the `Namespace` struct
clones the entire dependency graph). For error handling purposes in
sway-lsp we save the current namespace in `TypeCheckFailed` rather than
in `TyModule`, which also significantly reduces memory allocation during
compilation.
### Updated tests
A number of tests have been updated for various reasons:
- Improved or changed error messages
- Module visibility was not checked correctly, so some tests had to have
certain submodules made public.
- In once case, `core::str_slice` was referenced using the path
`::core::str_slice`. This is invalid, but since `core` used to be
treated as a submodule of every module in the program, the path resolved
anyway. (This also shows that the invalid paths in issue #5498 are now
actually treated as invalid - I have not added regression tests of that
issue, since it seems unlikely that we will reintroduce the bug).
### Unresolved issues
- The `Namespace` struct is cloned before the symbol collection phase.
This is expensive, since the `Namespace` struct at that point contains
the entire dependency graph (minus the modules of the current package).
Ideally we would like the symbol collection phase and the typechecker to
use the same `Namespace` struct, but at the moment the Module struct is
unable to perform updates from parsed to typechecked declarations, so
this isn't possible. The cloning happens in `sway-core/src/lib.rs` and
`sway-core/src/semantic_analysis/namespace/contract_helpers.rs`. Once we
represent externals as a global table we should be able to change the
`Root.externals` map to only use references into the global table, which
will make the cloning step much cheaper.
- `contract_helpers.rs` throws a regular compiler error if typechecking
fails, but that should be an ICE, since it is generated code that is
failing to typecheck.
- Paths may in some cases escape from external packages to the current
package. If this happens across multiple packages, then this may result
in the path no longer being valid. For instance, if A depends on B,
which in turn depends on C, then a path may escape from C via B into A,
but since A does not have C as a direct dependency, then the path can no
longer be resolved. This again can be fixed once we introduce a global
table of externals.
- The visibility check in `type_resolve.rs` is insufficient, because it
doesn't handle enum variants and associated types correctly.
## 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: João Matos <joao@tritao.eu>
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
SIgnificantly reduces bytecode sizes by transforming the following
commonly-used operations when the constant value fits into the immediate
part of the `*i` variant of the instruction:
* `MOVI(tmp, copy_len); MCP(dst, src, tmp)` → `MCPI(dst, src, copy_len)`
(in `compile_mem_copy_bytes`)
* `MOVI(dst, offset); ADD(dst, dst, DATA_SECTION)` → `ADDI(dst,
DATA_SECTION, offset)` (in `addr_of`)
## Checklist
- [ ] I have linked to any relevant issues. (none that I know of)
- [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). (no changes required)
- [ ] 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. (partially; some values in tests got smaller. we don't
seem to be tracking the size and size regressions in tests)
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant. (not 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
This PR implements the missing elements for the hierarchical lexical
scopes.
TypeCheckContext no longer uses cloned namespaces. Instead, we push and
pop lexical scopes.
For this to work multiple places that used current_items now either use
root_items or traverse the lexical scopes.
## 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.
---------
Co-authored-by: João Matos <joao@tritao.eu>
Co-authored-by: IGI-111 <igi-111@protonmail.com>
## Description
When using literal on array reasignement we were not checking the array
length. We now throw an array oob error in this case.
Fixes#6393
## 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>
This adds a mapping from a lexical scope to the declaration that
lexically corresponds to it.
This is necessary for some upcoming collection context PR.
## 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
Changes `SubstTypesContext` to contain an optional `TypeSubstMap`.
This is to make this usable from collection context where no type
substitution needs to be done.
## 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
[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 implements a hierarchical-based trait map and namespace lookup
system while type checking.
Previously we added the concept of lexical concepts, which store all the
names in a tree-based hierarchy.
But currently we still rely on a single "global" namespace, which is
maintained by the type check context as we go down the tree. Thus, so
far, all trait and namespace lookup have relied on looking up in that
single namespace.
The main idea here is to be able to just rely on the names existing in
the lexical scopes, and walk up those lexical scope chains as we need to
lookup any name or trait.
The logic is split into these two commits:
[Implement hierarchical trait map
lookups.](4043fb5bcb)
[Implement hierarchical namespace
lookups.](486df45623)
This PR still does not remove that cloning, which will be done in a
separate future PR.
## 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
Another round of namespace-related cleanups.
## 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 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
The parser no longer parses qualified call paths without the `as` token
and trait.
This invalidates code that was previously accepted such as: `let x:
<u8>::S::<u8> = S::<u8>{x: 8};`
Fixes#6389
## 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>
The added test case was emitting a wrong/confusing error message,
because a for loop only gets type-checked in its desugared form, as a
while loop.
The error message was `A while loop's loop body cannot implicitly return
a value. Try assigning it to a mutable variable declared outside of the
loop instead.`
Corrected to: `A for loop's loop body cannot implicitly return a value.
Try assigning it to a mutable variable declared outside of the loop
instead.`
Fixes#6395
## 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)
- [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
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 improve value propagation optimization in two ways:
1 - First, when the optimizer knows that both source and destination
registers of the `MOVE` instruct have the same value and version; it
will remove the instruction as it is useless;
2 - Otherwise, we propagate the value saying that destination now have
the same value and version of the source register for other
optimizations.
## 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 https://github.com/FuelLabs/sway/issues/6569
## 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.
Re-enabling this feature after a bugfix. (reverted PR: #6522)
---------
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
Co-authored-by: IGI-111 <igi-111@protonmail.com>
## Description
Fixes#6673.
The module visibility check has been broken for some time.
In some cases, like the one described in #6673, this has resulted in
modules being mistakenly regarded as inaccessible, even though they
ought to be accessible.
In other cases, private modules were mistakenly regarded as accessible.
For examples see the updated tests in the PR.
The check has now been fixed, and all tests have been updated
accordingly.
This bugfix can be regarded as a breaking change, because some modules
that were deemed accessible before may now be deemed inaccessible and
will require the addition of a `pub` keyword in front of the module
declaration.
## 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
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 pull request adds the profile feature in the Sway compiler.
It communicates with an external `forc-perf` executable in order to
signal the beginning and end of different compilation phases for
profiling purposes.
(re-opening of https://github.com/FuelLabs/sway/pull/6565)
## 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: Camden Smallwood <camden.smallwood@gmail.com>
Co-authored-by: GeorgiosDelkos <georgios.delkos@ourovoros.io>
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
This PR brings back encode/decode buffer ownership tests and closes
https://github.com/FuelLabs/sway/issues/6567.
The original issue was that an error in the CI file was hiding that
these tests were not compiling anymore.
IR generation now also tests the expression and the variant type match,
giving a better error than before.
## Checklist
- [x] I have linked to any relevant issues.
- [ ] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
This PR implements a major rewrite of the `TypeEngine`. The rewrite:
- significantly improves overall compilation performance. The
compilation time of the real-world [Spark Orderbook
workspace](https://github.com/compolabs/orderbook-contract) got
**reduced from 8.99 to 5.94 seconds**, and the memory consumption from
**3.32 to 1.78 GB**.
- provides robust API for inserting types, related to the usage of the
`source_id` (see: #5991). The new API forbids not providing `source_id`s
or providing semantically questionable or non-optimal ones.
- introduces simpler, much less verbose, API for inserting types.
The PR also removes the obsolete and unused `TypeInfo::Storage`.
The PR **does not address** the following:
- The `TypeEngine`'s "garbage-collection-(un)friendlines" (see: #6603).
- The handling of the `TypeInfo::Custom` and `TypeInfo::TraitType` types
within the `TypeEngine` (see: #6601).
- The number of interactions with the `TypeEngine`. E.g., removing
unnecessary insertions after `resolve()`ing or `monomorphyze()`ing types
will be done as a part of `DeclEngine` optimization.
Closes#5991.
## Shareable types
The PR formalizes the notion of a _shareable type_ within the
`TypeEngine` (strictly speaking, a shareable `TypeInfo`). A shareable
type is a type that is both:
- _unchangeable_: it, or any of its parts, cannot be replaced during the
unification or monomorphization.
- and _undistinguishable by annotations_: it doesn't carry any
additional information (annotations) that could differ it from another
instance of `TypeInfo` that would, purely from the type perspective, be
a same type.
E.g., `u64` or `MyStruct<u64, bool>` are unchangeable while `Numeric`,
`Unknown` or `MyStruct<T1, T1>` are changeable.
E.g., in this example, `a` and `b` have the same type, `[u64; 2]` but
those two types differ in spans assigned to the "u64"s and the "2"s, and
are treated as different within the `TypeEngine`, and thus as
non-shareable.
```
let a: [u64; 2] = [1, 1];
let b: [u64; 2] = [2, 2];
```
Shareability of a type is crucial for reusing the `TypeSourceInfo`
instances within the type engine. Shareable types can be given different
`TypeId`s without the need to newly allocate a `TypeSourceInfo`.
## Performance improvements
The cummulative effect of the performance improvements on the
compilataion of the real-world [Spark Orderbook
workspace](https://github.com/compolabs/orderbook-contract) is given
below. The compilation means the frontend compilation, up to the IR
generation (`forc check`).
**Compilation time**
```
Before:
Time (mean ± σ): 8.995 s ± 0.297 s [User: 7.126 s, System: 1.289 s]
Range (min … max): 8.675 s … 9.262 s 3 runs
After:
Time (mean ± σ): 5.945 s ± 0.517 s [User: 4.749 s, System: 0.768 s]
Range (min … max): 5.349 s … 6.280 s 3 runs
```
**Memory consumption**
```
---------------------------------------------------------
total(B) useful-heap(B) extra-heap(B)
---------------------------------------------------------
Before: 3,316,786,808 3,237,317,383 79,469,425
After: 1,784,467,376 1,743,772,406 40,694,970
```
### Applied optimizations:
- **Replacement of expensive `insert` calls with compile time constants
for built-in types.** Built-in types like `!`, `bool`, `()`, `u8`, etc.
are inserted into the engine at its creation at predefined slots within
the `slab`. The `id_of_<built-in-type>` methods just return those
predefined `TypeId`s, effectively being compiled down to constants. The
calls like `type_engine.insert(engines, TypeInfo::Boolean, None)` are
replaced with maximally optimized and non-verbose
`type_engine.id_of_bool()`.
- **Elimination of extensive creation of `TypeSourceInfo`s for
`TypeInfo::Unknown/Numeric`s.** `Unknown` and `Numeric` are inserted
into the engine ~50.000 times. Each insert used to create a new instance
of `TypeSourceInfo` with the `source_id` set to `None`. The optimization
replaces those ~50.000 instances with two predefined singleton
instances, one for `Unknown` + `None` and one for `Numeric` + `None`.
(Note that when implementing #6603, we will want to bind also `Unknown`s
and `Numeric`s to `source_id`s different then `None`, but we will still
want to reuse the `TypeInfo` instances.)
- **Elimination of extensive temporary heap-allocations during hash
calculation.** The custom hasher obtained by `make_hasher` required a
`TypeSourceInfo` to calculate the hash and it was called every time the
`insert` was called, ~530.000 times. Getting the `TypeSourceInfo`
originally required cloning the `TypeInfo`, which depending on the
concrete `TypeInfo` instance could cause heap allocations, and also
heap-allocating that copy within an `Arc`. Hash was calculated
regardless of the possibility for the type to be stored in the hash map
of reusable types. The optimization removed the hashing step if the type
is not shareable, removed the cloning of the `TypeInfo` and introduced a
custom `compute_hash_without_heap_allocation` method that produced the
same hash as the `make_hasher` but without unnecessary temporary
heap-allocations of `TypeSourceInfo`s.
- **Replacement of `TypeSourceInfo`s within the hash map with
`Arc<TypeSourceInfo>`s.** The hash map unnecessarily required making
copies of reused `TypeSourceInfo`s.
- **Introducing the concept of a _shareable type_ and rolling it out for
all types.** Previously, the engine checked only for changeability of
types by using the `TypeInfo::is_changeable` method. The implementation
of that method was extremely simplified, e.g. treating all structs and
enums with generic arguments as changeable even if they were fully
monomorphized. This resulted in over-bloating the engine with type
instances that were actually unchangeable, but considered to be
changeable. Also, strictly seen, the unchangeability (during unification
and monomorphization) is not the only necessary criteria for reuse (or
sharing) a type within the engine. Another important aspect is, as
explained above, the _differentiability by annotations_. The PR
introduces the notion of a _shareable type_ which is both unchangeable
and not differentiable by annotations. The optimization takes advantage
of such types by storing them only once per `source_id`.
- **Elimination of extensive unnecessary inserts of new types during
`replace()` calls.** When `replace()`ing types during unifications, a
new `TypeSourceInfo` instance was created for every replacement, ~46.000
times. This meant a heap-allocation of the `TypeSourceInfo` (16 bytes)
and the `Arc`-contained `TypeInfo` (232 bytes), even if the replaced
type was shareable and already available in the type engine. The
optimization now reuses an already existing shareable type if available.
## Robustness related to `source_id`s
The issues we had with properly providing the `source_id` in the
`insert` method are explained in #5991. This PR removes the `source_id`
from the new public API and calculates it internally within the engine,
based on the type being inserted. This makes inserting of types both
more robust and less verbose and eliminates the possibility of providing
a semantically wrong `source_id`.
Note that the calculation of an optimal `source_id` done within the
engine fully corresponds to the "calculations" we currently have at call
sites.
E.g., when inserting enums, previously we always had to write
`type_engine.insert(engines, TypeInfo::Enum(decl_id),
enum_decl.span.source_id())`. Fetching the `source_id` from the enum
declaration is now done within the `insert_enum` method:
`type_engine.insert_enum(engines, decl_id)`.
Note that for certain types we will want to change the current behavior
and either provide a `source_id` or pick a more suitable one. E.g, even
when inserting `Unknown`s, we will want to have `source_id`s, if
possible. This will be done in #6603, but again, together with providing
a robust API that will be difficult to misuse.
## Simplicity
As already mentioned in some of the examples above, the new
`id_of_<type>()` and `insert_<type>` methods provide much simpler and
less verbose API to use. Introducing those methods remove a lot of
boilerplate code from the callers. Also, the individual `insert_<type>`
methods are additionally optimized for inserting the particular type.
The common `insert` method is intended to be used only in cases where
the inserted `TypeInfo` is not known at the call site.
Here are some examples of the new API versus the existing one:
|Before|After|
|------|-----|
| `type_engine.insert(engines, TypeInfo::Tuple(vec![]), None)` |
`type_engine.id_of_unit()` |
| `type_engine.insert(engines, TypeInfo::Unknown, None)` |
`type_engine.new_unknown()` |
| `type_engine.insert(engines,
TypeInfo::UnsignedInteger(IntegerBits::SixtyFour), None)` |
`type_engine.id_of_u64()` |
For more complex types, like, e.g., `TypeInfo::Tuple`, the difference in
inserting is even more prominent, as can be seen from the diffs of
numerous code lines deleted in this PR.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
---------
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
Co-authored-by: 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>
The preamble now contains 8 bytes of offset to the configurables
section. If there is no configurable const in the data-section, then the
value of this integer will be equal to the size of the binary itself.
This also means that we now sort the data-section to have all the
non-configurables first, and then the configurables.
The preamble final asm looks like this (the offset to configurables is
0'd out here in the example):
```
;; ASM: Final program
;; Program kind: Script
.program:
move $$tmp $pc
jmpf $zero i10
DATA_SECTION_OFFSET[0..32]
DATA_SECTION_OFFSET[32..64]
CONFIGURABLES_OFFSET[0..32]
CONFIGURABLES_OFFSET[32..64]
lw $$ds $$tmp i1
add $$ds $$ds $$tmp
```
The preamble bytecode looks like this:
```
0x00000000 MOVE R60 $pc ;; [26, 240, 48, 0]
0x00000004 JMPF $zero 0xa ;; [116, 0, 0, 10]
0x00000008 ;; [0, 0, 0, 0, 0, 0, 2, 40]
0x00000010 ;; [0, 0, 0, 0, 0, 0, 0, 0]
0x00000030 LW R63 R60 0x1 ;; [93, 255, 192, 1]
0x00000034 ADD R63 R63 R60 ;; [16, 255, 255, 0]
...
```
---------
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
Co-authored-by: IGI-111 <igi-111@protonmail.com>
## Description
This PR fixes https://github.com/FuelLabs/sway/issues/6382.
The issue was that `TypeParameter::type_check_trait_constraints(...)`
mutates the type inside the `TypeEngine`, but it was not returning the
new type-checked trait constraints.
## 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
This PR removes `root_type_id` from `TypeInfo::Custom`.
This was used for resolving `Self` in associated types, but it's not
needed, we can resolve those using the regular `self_type` we pass to
name resolution.
## 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: IGI-111 <igi-111@protonmail.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
Adds `TypeInfo::UntypedEnum` and `TypeInfo::UntypedStruct`, which are
used to represent untyped enums/structs pointing to a `ParsedDeclId`.
These will be used for an upcoming PR that does name resolution as a
standalone step before type 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.
## Description
The return path analysis ensures that if a method must return a value
then the spine of the method returns a value. The analysis traverses a
linearized version of the CFG (one which ignores branching expressions
such as `if-then-else` and loops, and simply treats them as a single
node) of each method from the (unique) entry point to the (unique) exit
point. If there is ever a node in the graph that does not have outgoing
edges, then an error is thrown.
When constructing such a linearized CFG we have so far treated local
`impl`s as branches, meaning that the spine was in fact not linear:
```
fn main() -> u64 {
// This point has two outgoing edges
// One goes to here
impl core::ops::Eq for X {
fn eq(self, other: Self) -> bool {
asm(r1: self, r2: other, r3) {
eq r3 r2 r1;
r3: bool
}
}
}
// The other goes to here
if X::Y(true) == X::Y(true) {
a
} else {
a
}
}
```
This has been the case even though the edge into a local `impl` does not
in fact represent legal control flow.
This incorrect construction has made the traversal of the spine-CFG very
convoluted and difficult to follow.
This PR fixes the incorrect construction, and simplifies the traversal
of the spine so that it is clear what is going on. I have also added an
additional test to show that methods inside local `impl`s are in fact
analyzed separately, even though there is no longer an edge going into
the `impl` from the surrounding function.
## 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>
Co-authored-by: João Matos <joao@tritao.eu>
## Description
This PR represents another round of cleanups, this time mostly around
`Namespace` and `Root`.
## 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>
To save excess arguments on the stack, previously we would
1. store the argument using SW with an immediate offset basing from
locals-base register. This limits the offset to 12 bits.
2. Store the offset to the first excess argument to the last ARG
register so that callee can access these.
This PR reverses the order. It stores the offset to the last ARG
register first. Then the store of argument to the stack slot can be made
without requiring large immediate offsets, basing just on the last ARG
register.
Fixes#6646
---------
Co-authored-by: IGI-111 <igi-111@protonmail.com>
## Description
When importing items we allow imports from ancestor modules, even if the
ancestor module is declared as private.
The code that performs this check was moved from `module.rs` to
`root.rs` as part of #5697. During this move the current module path
(i.e., the path of the destination of the import) was mistakenly
replaced with the module path of the root module of the destination
module. Since root modules do not have ancestors this meant that no
source module was ever considered an ancestor of the destination module.
This PR fixes this problem, and adds an abscure test case that shows the
issue.
## 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
When a method application called another one that uses more type args
than the impl trait type args the type substitution was not working.
This was fixed by making a type substitution of placeholders of impl
trait type parameters.
## 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: João Matos <joao@tritao.eu>
## Description
ContractCaller comparison was too restrictive, we now just check if the
span matches. This fixes unification of codeblock first pass variables
with second pass variables.
Fixes [#6614](https://github.com/FuelLabs/sway/issues/6614)
## 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: João Matos <joao@tritao.eu>
## Description
This PR fixes an issue with array items that are typed as
`TypeInfo::Error`. These errors were being swallowed and the compiler
was failing later with an ICE.
Now we correctly show the more user-friendly error.
```
--> test/src/e2e_vm_tests/test_programs/should_fail/array_wrong_elements_types/src/main.sw:51:26
|
49 |
50 | // Literal too big
51 | let mut a = [8u8, 8, 18446744073709551615];
| ^^^^^^^^^^^^^^^^^^^^ Literal value is too large for type u8.
52 | }
```
## 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: Joshua Batty <joshpbatty@gmail.com>
## Description
This PR improves `fn_dedup` to also deduplicate config decode functions.
Given how early this optimization was running, some optimizations were
being lost, because some functions only get identical at the final IR. I
believe we chose to run this early to decrease the pressure in other
passes, but to allow this pass to really coalesce decodes I think makes
sense to run it again at the end.
I am also deleting from the IR functions that were being replaced. This
allowed the new test to decrease around 100 bytes. Our old configurable
test went from 7600 to 7250 bytes.
## 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: Joshua Batty <joshpbatty@gmail.com>
Co-authored-by: IGI-111 <igi-111@protonmail.com>
Co-authored-by: Kaya Gökalp <kaya.gokalp@fuel.sh>
## Description
This PR mainly refactors some common monomorphization/type resolving
code out of `TypeCheckContext`, to be able to re-use this code for the
symbol resolving pass as well, along with some other minor cleanups.
It also helps with code quality in that this file is a big beast and so
this makes it a bit more manageable to understand.
Main changes:
[Refactor symbol resolve from root into lexical
scope.](742067df89)
[Refactor monomorphization/type resolving code out of
TypeCheckContext.](58c83da8a1)
[Extract resolve_qualified_call_path_with_visibility_check_and_modpath
to type
resolver.](d50f598d30)
[Extract resolve_call_path_with_visibility_check_and_modpath to type
resolver.](940a67700e)
[Refactor type resolver trait into
functions.](77c6a27e56)
---------
Co-authored-by: IGI-111 <igi-111@protonmail.com>
## Description
This PR removes redundant `cfei/cfsi` and `cfe/cfs` instructions from
the allocated abstract instruction set, if the allocated/dealocated
stack size is zero.
Note that, in the case of `cfei/cfsi i0` the removal does not represent
an optimization, because those instructions were anyhow removed at the
final bytecode generation step (see #5588). The PR in this case merely
synchronizes the finalized ASM with the generated bytecode, removing
potential confusion caused by existence of redundant zero stack
allocations in the printed final ASM.
The removal of redundant `cfei/cfsi` and `cfe/cfs` instructions _must be
done on the allocated instruction set_, because the register allocation
could change the original allocated/dealocated size in case of spilling.
Related to #5588.
## 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
"miden" crate was yanked, so this is the minimal changeset to remove it
as a dependency.
We may still keep some `miden` stuff around.
## 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 fixes the array element type selection algorithm to avoid
selecting `Never`.
## Checklist
- [ ] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## 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
This PR does a couple things:
* Creates all of the necessary lexical scopes in the collection context
namespace
* Introduces the collection context in the type check context
* Updates type checking code to enter the corresponding lexical scope in
the collection context
* Introduces a mapping from a span to a lexical scope in the namespace
* Implements collection steps for so far unimplemented AST nodes
This prepares the compiler for a future PR where the additional
namespace will be able to be removed from the type checking, and with it
the cloning we do as we type check.
## 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: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
## Description
An optimization on
`check_if_trait_constraints_are_satisfied_for_type_inner` was making
missing trait constraints not being detected.
Fixes#6374.
## 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
Fixes a bug that would crash the language server when a function node
was part of the AST.
#5967 added a function cache to the `QueryEngine`. Garbage collection
needed to be called on this otherwise it returns references to types
that have been cleared from the other engines during garbage collection.
In the future, any other nodes that we decide to cache need to have GC
applied to them or we will end up crashing the language server on the
first key-pressed event.
I've also removed the gc_frequency setting and now run GC on each
keystroke. Without doing this, the spans stored in the TokenMap and what
was returned from the compiler were falling out of sync. This ensures
that everything is always up to date and the correct spans are used.
closes#5260
Finally, I've added a `launch.json` that allows for attaching `lldb` to
a live running `forc-lsp` process. This was a pretty cruical step for
tracking down this bug so would be nice to have it easily accessible for
future debugging sessions.
## 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>
