## Description
This implements a set of optimizations around span usage. The main idea
is we stop using paths as strings, and instead replace it using an
integer-based id, which is way less expensive for hash map comparisons.
Here are some numbers, from the slowest test we have on the suite
(`should_pass/stdlib/vec`).
**Benchmarking Results** (`master`):
**Time** (mean ± σ): 6.129 s ± 0.080 s [User: 5.755 s, System: 0.359 s]
**Range** (min … max): 6.009 s … 6.268 s 10 runs
**Benchmarking Results** (span hash optimization):
**Time** (mean ± σ): 5.345 s ± 0.161 s [User: 5.000 s, System: 0.341 s]
**Range** (min … max): 5.082 s … 5.590 s 10 runss
**Benchmarking Results** (both span hash and SourceEngine optimization):
**Time** (mean ± σ): 4.376 s ± 0.089 s [User: 4.065 s, System: 0.309 s]
**Range** (min … max): 4.255 s … 4.546 s 10 runs
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
Waiting for:
- #4525.
@Dhaiwat10 was waiting for a release with the linked PR merged.
@IGI-111 I had the PR ready, leaving it up to you when to merge & cut
the release. Made this a major bump as we had a breaking change merged
(#4574).
## 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).
- [ ] 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 also handles ambiguities in cases where a lone ident is either a
variable or a variant; or a variable declaration or an enum scrutinee.
Fix#4480
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
This change mainly adds checks to enforce the new module privacy rules
and supporting changes for it.
Changes include updating std and core to use
public modules, updating the parser to allow the use of the `pub mod`
syntax and adding an error type for private modules.
This change is implemented behind a `--experimental-private-modules`
experimental flag and not enabled by default.
It implements part of https://github.com/FuelLabs/sway/issues/4446, the
`pub use` syntax is yet to be implemented.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
See here for context:
https://github.com/FuelLabs/sway/pull/4492#issuecomment-1520949069
This follows a re-release of 0.37.1 as 0.37.3:
https://github.com/FuelLabs/sway/releases/tag/v0.37.3
The outcome of all this is that ideally, users previously on 0.37.1 will
now pull 0.37.3 next time they run `cargo update` and will not encounter
any breakage. Those ready to update can point to 0.38.0 after this is
published.
Also runs `cargo update` in order to update deps to their latest patch
release.
---------
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
Allow users to specify match patters such as:
```sway
let x = 1;
match x {
0 | 1 => true,
_ => false
}
```
We also check that all patterns in a disjunction declare the same set of
variables (not doing so is an error).
Fix https://github.com/FuelLabs/sway/issues/769
This requires a change in the pattern matching analysis to remove the
assumption that a specialized matrix of a vector pattern is always a
vector, which is now no longer true because or patterns can generate
multiple branches and therefore multiple rows.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
Enable the LSP renaming functionality for all tokens within the users
workspace. Makes sure to not allow the renaming of keywords, intrinsics,
or types defined outside of the workspace.
Note, renaming of modules is not yet supported but I have an issue to
follow up on this at #4289.
closes#2261closes#1418
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
## Description
The idea is to not check for Sway keywords when parsing the opcodes in
`asm` blocks. This is important because some Sway keywords, such as
`mod`, are also FuelVM opcodes. Note that the validity of the opcodes
are later checked anyways so we're not losing any useful checks here.
## 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).
- [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.
Moves following `Cargo.toml` fields to workspace `Cargo.toml` so we
don't have to keep repeating ourselves:
- edition
- authors
- homepage
- license
- repository
## Description
This splits off the parsing and semantic analysis changes out of
https://github.com/FuelLabs/sway/pull/4036 into a bunch of commits:
[Implement associated constants in traits and
ABIs.](c333b4d740)
[Added multiple definition error name checking to
traits.](88dc9d1430)
[Refactor namespace method resolving code to be
item-based.](5d2eb6f177)
[Add constants to the trait namespace and map to allow referencing from
methods](d4c48f7210)
This one adds a bunch of disabled tests, next PR will enable them with
corresponding IR generation changes and docs.
Related to https://github.com/FuelLabs/sway/issues/3797.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
This PR adds `mod sway_parse::test_utils` containing two utils, `fn
parse<T>` and `fn parse_to_end<T>`, to replace non-generic utils like
`fn parse_item` or `fn parse_path_expr`.
- Implements `serde::Serialize` for `sway_ast::Module` and such.
- Adds a simple integration test to `sway_parse` which uses `insta` for
RON snapshot testing.
This should allow us to dump AST in more convenient formats and also use
tools like `insta` to do testing on the serialized output.
Note: Deserialization was left for later.
## Description
Closes#3938
### Problem
I've submitted a few PRs (#4129, #4093, #4005) implementing a new way of
formatting comments in tackling #3938, but after submitting #4129 and
following that working on formatting storage comments in a local branch
realized that the method of formatting previously by writing
`write_comments(..)` between every span is getting very unwieldy. That
method results in a lot of repeated calls to `write_comments()`, and in
some cases where we have to check if some value exists, it would lead to
even more vertical space taken up because we have to do something like
this:
```rust
...
if let Some(item) = my_item {
write_comments(
formatted_code,
start..end,
formatter,
)
// do other things
}
...
```
My sense is that this will probably lead to the formatter code being
hard to maintain in future because of the length of each `Format`
implementations, and having to work your way through a lot of
conditional code and repeated calls to `write_comments(..)` isn't a very
nice experience. In #4005, the comment formatting for `ItemAbi` alone
led to **56 additional line insertions** in that PR (previously it was
54 LoC, which means the LoC doubled!)
### Solution
We adapt the original approach of inserting comments, but this time on a
local scale. That means we parse each node on its own, compare its
unformatted and formatted versions, and find out where to insert
comments found between spans. Unlike the original approach, this
approach will parse and format while the AST node is being visited and
formatted - that means the entire `handle_comments(..)` that reparses
the entire `Module` can be deprecated once this PR is in.
This is done mainly through the function `rewrite_with_comments(..)`
that is called at the end of a `impl Format`. Essentially what this
function does is it parses the unformatted and formatted versions of the
currently visited node with `parse_snippet::<P: sway_parse::Parse +
Format>(..)`, finding the comments between the unformatted spans, and
inserting them into the formatted spans.
Based on the `CommentKind` of the found comments, we do some formatting
to decide how they should be written.
Of course, this also means that unlike the previously proposed method of
using `write_comments()` everywhere, where we have the indentation
context, this new approach means that we yet again do not have the local
context. To figure out indentation, we assume that each comment will
always be 'pinned' to some node below it - if this node does not exist
we try to 'pin' to a node above it instead.
## 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).
- [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).
- [x] I have requested a review from the relevant team or maintainers.
## Description
Implement RFC 0006, fix#4191.
Remove the `dep` reseved keyword in favor of `mod`.
Change path resolution for submodules to use an adjascent file at the
root and a folder named after the current module in other cases.
Remove the need for an argument to `library`, the LSP now points to
empty spans at the top of module files.
The library names are now determined by the file name, or the package
name at the top level.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
Refactor the `DeclEngine` to use generic `DeclId`s that carry the type
of the declaration they point to with them. This allows us to avoid a
*lot* of unnecessary error handling and passing around of spans.
`DeclId` types mostly to not mix except in the case of Functions and
TraitFns, in this case we use a FunctionalDeclId enum to mix them in a
way they can still be discriminated by the user.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
Followup to #4005
makes `abi_supertraits` test pass comment formatting without
`handle_comments`.
In fixing this, this also inadvertently led to me fixing other
formatting issues:
- There may be comments before the module declaration - the first one
was tagged as a `Trailing` comment, even though it should not be. Added
a 0 check within lexing for this.
- Massively simplified `comments.rs` - before, we used to arbitrarily
compare to the previous token, but now that we have the concept of
`Trailing` and `Newlined` comments, we do not need to do this. We also
used to write an indent after writing a trailing comment, but I think
this should be moved up-one-level to whereever the trailing comment was
written. There is also an update to a test that retains the trailing
nature of a trailing comment in an existing test.
For the rest of changes, they seem largely unrelated to what this PR
claims to solve, so I'll go change by change:
- within `item_fn/mod.rs`: This fixes the supertraits test example
(which had a weird spacing for expected comment output)
- within `module/mod.rs`: We format comments between items (this fixes
the the tests like `abi_comments` and `abi_supertrait` that have
comments written between items.
## 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).
- [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).
- [x] I have requested a review from the relevant team or maintainers.
## Description
This splits off the refactoring changes out of
https://github.com/FuelLabs/sway/pull/4036 into two commits:
[Rework trait/ABI/impl-related structures to be
item-based.](3a8d6ea2c8)
[Refactor constant items/decls to have an optional
expression.](3ec09035b4)
No functional changes intended.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
Adds module level docs & previews to `forc doc`.
[Screencast from 2023-02-20
20-30-24.webm](https://user-images.githubusercontent.com/57543709/220232486-7ec0742a-59ef-41c9-a459-3c8c9b7d42c7.webm)
## Checklist
- [x] I have linked to any relevant issues. Closes#4095
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
Part of #3938
This PR handles **comment formatting** for the abi,
as well as comments before modules (this is to pass the test suite)
This was a pretty tricky PR to tackle, since I cycled through several
thought processes while trying to finish this.
1) I tried to solve the problem at the parse/lex level - cycled back to
the thought of re-parsing the file to create a special commented AST -
worked a bit on that before I scrapped the whole idea because it just
didn't seem necessary.
2) I then started trying to solve it in the originally discussed way,
attempting to format the comments within each `Format` implementation.
This started off well - it was trivial to navigate within a span, but it
was particularly tricky navigating _between_ spans, and for formatting
the ABI, it turns out that trailing comments can appear after an
attribute, or even after the fn signature. I initially tried to
implement a way to 'look forward', but soon realized it was impossible
unless we want to hold a reference to the unformatted code in each
`Format` implementation (which I guess is what I ended up doing anyway)
3) So, I ended up looking for a way to 'look back', but still used 'look
ahead' for comments:
Comments will always be 'anchored' to the next span - meaning to say,
when a trailing comment exists, it will 'belong' to the next span
instead of the span(s) on the same line. This means that when we know
the locations of 2 spans, we can easily call `write_comments` to insert
the comments in between.
While we mentioned that looking forward is impossible, one place we
_can_ look forward though, is between comments in the unformatted code,
if there are multiple comments to be written at once. This is basically
what `collect_newlines_after_comment_span()` is doing.
### Other notable changes
- Renamed `write_comments_from_comment_map` to `write_comments` to be
more concise.
- Introduce `CommentsContext` to hold both `CommentMap` and
`unformatted_code`, instead of exposing `unformatted_code` at the
Formatter level.
- Changed generic `T` to `ItemKind` within attribute.rs. This is so we
can have access to `span()`.
- Lexing the commented token tree now gives us `CommentKind` info.
## 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).
- [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).
- [x] I have requested a review from the relevant team or maintainers.
---------
Co-authored-by: Kaya Gökalp <kaya.gokalp@fuel.sh>
## Description
Ran on test branch & working as intended. Only beginning of file `//!`
is collected as `DocComment` with `DocStyle::Inner` which is only
collected at the `Module` parsing stage. This ensures that any `//!`
found after the module docs will be treated as normal comments for now.
Ref #4112 for tracking further progress in allowing inner doc comments
for `Item`.
## Checklist
- [x] I have linked to any relevant issues. Closes#4097
- [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).
- [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
Please see the issue #3798.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Tasks
- [x] check the supertrait(s) for the ABI is implemented
- [x] fail with an error when a supertrait for ABI is not implemented
- [x] check that ABI implementation methods can use its supertrait's
methods (the one that are defined at the ABI _declaration_ site)
- [x] check that the supertrait's methods can be used in the actual
contract methods
- [x] check that methods in supertraits are not be available externally
(i.e. they're not actually contract methods)
- [x] implement that Ownable example
- [x] formatter tests
- [x] add new section in the Sway docs illustrating this language
feature
---------
Co-authored-by: Mohammad Fawaz <mohammadfawaz89@gmail.com>
## Description
Bump to `v0.35.0` for a new release.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
This PR provides documentation when hovering over keywords in sway. I
copied over the documentation for keywords that are shared with rust and
tweaked them so they made sense to sway [from
here](https://github.com/rust-lang/rust/blob/master/library/std/src/keyword_docs.rs
).
It would be great to get some compiler engineers to look over the
documentation to make sure nothing is being incorrectly defined.
There are still a number of keywords that need documentation written up
for them but I've opened up #3939 so these can be added by someone on
the compiler team at a later date.
will close#3515
---------
Closes https://github.com/FuelLabs/sway/issues/1498
This PR adds configuration-time constants as described in Ref
https://github.com/FuelLabs/sway-rfcs/pull/19. There is still some work
to be done, namely:
- https://github.com/FuelLabs/sway/issues/3680
- https://github.com/FuelLabs/sway/issues/3679
- https://github.com/FuelLabs/sway/issues/3678
- https://github.com/FuelLabs/sway/issues/3306 (expanding that issue to
consider all types of constants)
as well as some work in the SDKs and in `forc` to override these
constants at deploy-time.
The design of this feature is relatively simply:
### Key Points
- Configuration-time constants are declared using a `configurable` block
which is quite similar to a `storage` block. It also requires that each
config constant is initialized (just like storage variables).
- Configuration-time constants show up in the JSON ABI as described in
the [ABI
spec](https://fuellabs.github.io/fuel-specs/master/protocol/abi/json_abi_format.html)
- There is a 1:1 mapping between each configuration-time constant and a
particular location in the data section. The amount of bytes consumed in
the data section is dependent on the type of the constant.
- The optimizer guarantees that configuration-time constants are not
optimized in any way.
- The IR represents configuration-time constants are global scope (see
IR tests)
- Configuration-time constants are not allowed in libraries for the time
being.
### Parser
Converts a `configurable` block into a list of constant declaration with
a new field that indicates whether the constant is configurable or not.
In other words, the concept of a configurable block does not exist after
`convert_parse_tree`.
### Frontend
The type checker is virtually unchanged.
### IR Gen and IR
Simply special casing global constants that have `is_configurable =
true` and converting those to a special type of `Value`s called
`Configurable`. This makes sure that the optimizer knows not to touch
this type of values in any way.
I also had to add a new metadata to keep track of the name of each
config. This is important to know what data value corresponds to what
config const in codegen because that information is useful for the JSON
object.
### Codegen
Mostly the same as regular constants except that we need to be careful
about merging data values that are the same. We continue to merge values
for regular consts but we make sure that configuration consts are
uniqued and get their own unshared spot.
### JSON ABI
The configuration consts and their types are added to the JSON object in
the frontend as usual. We later modify the object and add the actual
bytecode offsets as computed in codegen.
### Raw Tasks:
- [x] Parser
- [x] Frontend
- [ ] (deferred) Disallow multiple `configurable` blocks: will do this
separately in https://github.com/FuelLabs/sway/issues/3678
- [x] new IR `Value` type: `Configurable`
- [x] Printing
- [x] Parsing
- [x] New metadata `config_name`
- [x] IR Gen, especially on `const_eval`
- [x] Unit tests
- [x] ASM gen
- [ ] (deferred) Make sure unused configurable variables are still
included in the data section: See
https://github.com/FuelLabs/sway/issues/3680
- [x] Unit tests
- [x] Handling of data section and returning a map: config name ->
bytecode offset
- [x] JSON ABI generation + `forc-pkg` changes
- [x] E2E tests
- [ ] (deferred) Formatter. See:
https://github.com/FuelLabs/sway/issues/3679
