## Description
Fixes https://github.com/FuelLabs/sway/issues/6772.
## 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
Part of https://github.com/FuelLabs/sway/issues/6860.
This PR enables code like below to be written now. This will allow the
implementation of `iter()` for arrays.
```sway
struct S<T, const N: u64> {}
impl<T, const N: u64> S<T, N> {
pub fn len_xxx(self) -> u64 {
N
}
}
```
Limited to `structs` now. `enum` will be implemented in a future 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.
- [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 brings support for experimental features to the parsing phase.
This is needed so that we can support use cases like, e.g., adding new
language keywords behind a feature flag.
A concrete example would be the `panic` keyword added in #7073. The
parsing of the `panic` token differs if it is interpreted as a keyword
(when the `error_type` experimental feature is active) or as a regular
identifier (when `error_type` is off).
Because `ExperimentalFeatures` are needed in the `Parse::parse(parser:
&mut Parser)` methods, the `Parser` got extended with the `experimental`
field.
The consequence of bringing the `ExperimentalFeatures` to the parsing
phase is, that `swayfmt` and `forc fmt` can also require an experimental
feature to be set, to properly parse a project. In those tools,
`ExperimentalFeatures` are passed as a field on the `Formatter`.
Note that this PR does not put the provided experimental flags into use.
The first concrete usage will be in #7073.
This PR is a prerequisite for #7073.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
Currently update-contract-ids.sh cannot be run on any recent macOS
installation, as the system-provided grep and sed are incompatible with
the linux-specific options used. The GNU versions of these are available
through homebrew, so it would be nice to use those. Unfortunately, those
are installed with `g` prefix, so the binaries are named `gsed` and
`ggrep`. This PR changes the script to prefer these `g`-prefixed
commands, making the script work on macOS as well.
I tested this on a recent clean Ubuntu install, as well as latest macOS,
and it works on both.
## 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). N/A
- [ ] 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. N/A
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
This PR implements the `__dbg(...)` intrinsic, which is very similar to
Rust `dbg!(...)` macro.
Up until now, it has being the norm to use `__log` to debug values.
Given that this is NOT the first use case for log, we have always found
some issues with it: log does not work on predicates, log does not show
"private" fields like `Vec::capacity` and others.
To solve these problems `__dbg` is being introduced:
1 - it will work on all program types, including predicates;
2 - it also prints the file name, line and column;
3 - All types will have an automatic implementation of Debug if
possible, which can still be customized.
4 - Even `raw_ptr` and other non "loggable" types, have `Debug` impls.
5 - `__dbg` will be completely stripped in the release build by default.
It can be turned on again if needed.
So this:
```
// Aggregates
let _ = __dbg((1u64, 2u64));
let _ = __dbg([1u64, 2u64]);
// Structs and Enums
let _ = __dbg(S { });
let _ = __dbg(E::None);
let _ = __dbg(E::Some(S { }));
```
will generate this:
```
[src/main.sw:19:13] = (1, 2)
[src/main.sw:20:13] = [1, 2]
[src/main.sw:23:13] = S { }
[src/main.sw:24:13] = None
[src/main.sw:25:13] = E(S { })
```
How does this work?
`__dbg(value)` intrinsic is desugared into `{ let f = Formatter{};
f.print_str(...); let value = value; value.fmt(f); value }`.
`Formatter` is similar to Rust's one. The difference is that we still do
not support string formatting, so the `Formatter` has a lot of `print_*`
functions.
And each `print` function calls a "syscall". This `syscall` uses `ecal`
under the hood and it follows unix write syscall schema.
```sway
// ssize_t write(int fd, const void buf[.count], size_t count);
fn syscall_write(fd: u64, buf: raw_ptr, count: u64) {
asm(id: 1000, fd: fd, buf: buf, count: count) {
ecal id fd buf count;
}
}
```
For that to work, the VM interpreter must have its `EcalState` setup and
interpret syscall number 1000 as `write`. This PR does this for `forc
test` and our `e2e test suite`.
Each test in `forc test` will capture these calls and only print to the
terminal when requested with the `--log` flag.
## Garbage Collector and auto generated
Before, we were associating all auto-generated code with a pseudo file
called "<autogenerated>.sw" that was never garbage collected.
This generated a problem inside the LSP when the `auto_impl.rs` ran a
second time because of a collision in the "shareable type" map. When we
try to solve this collision, choosing to keep the old value or to insert
the new, the type inside the map points to already collected types and
the compiler panics. This is a known problem.
The workaround for this is to break the auto-generated code into
multiple files. Now they are named "main.autogenerated.sw", for example.
We create one pseudo-file for each real file that needs one.
When we garbage collect one file, `main.sw`, for example, we also
collect its associated auto-generated file.
## Checklist
- [ ] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
This PR is a prequel to https://github.com/FuelLabs/sway/pull/7015,
trying to optimize the compiler to alleviate the hit of having more
items, `impl` etc...
We have here two optimizations:
1 - We spend a lot of time counting newlines when converting byte
offsets to `LineCol`. Now, we calculate line offsets just once, and use
binary search later to find which line a byte offset is at.
2 - `QueryEngine::get_programs_cache_entry` was cloning the whole
`TyProgram`. That is why `did_change_with_caching` was always getting
worse, as the program was increasing in size. Now all compilation stages
are behind `Arc`, which makes the `clone` free.
## Analysis
Putting a `dbg!(...)` like the image below, and calling `counts`
(https://github.com/nnethercote/counts).
```
cargo bench -- traverse 2>&1 | grep "sway-types/src/span.rs:29:9" | counts
```
I get the following results:
```
972102 counts
( 1) 156720 (16.1%, 16.1%): [sway-types/src/span.rs:29:9] self.pos = 0
( 2) 15900 ( 1.6%, 17.8%): [sway-types/src/span.rs:29:9] self.pos = 104
( 3) 15840 ( 1.6%, 19.4%): [sway-types/src/span.rs:29:9] self.pos = 107
( 4) 2280 ( 0.2%, 19.6%): [sway-types/src/span.rs:29:9] self.pos = 19281
( 5) 2280 ( 0.2%, 19.9%): [sway-types/src/span.rs:29:9] self.pos = 19285
( 6) 2280 ( 0.2%, 20.1%): [sway-types/src/span.rs:29:9] self.pos = 19287
( 7) 2280 ( 0.2%, 20.3%): [sway-types/src/span.rs:29:9] self.pos = 19292
( 8) 2280 ( 0.2%, 20.6%): [sway-types/src/span.rs:29:9] self.pos = 19323
( 9) 2280 ( 0.2%, 20.8%): [sway-types/src/span.rs:29:9] self.pos = 19327
( 10) 2280 ( 0.2%, 21.0%): [sway-types/src/span.rs:29:9] self.pos = 19329
( 11) 2280 ( 0.2%, 21.3%): [sway-types/src/span.rs:29:9] self.pos = 19334
( 12) 870 ( 0.1%, 21.4%): [sway-types/src/span.rs:29:9] self.pos = 4285
...
```
This means that `line_col` is being called 972k times. 16% is for
position zero, which should be trivial. The rest will iterate the whole
file source code to count number of lines. Making the real complexity of
the work here something like `O(qty * self.pos)`. And some values of
`self.pos` are not trivial at all.
## 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 optimizes the `std::auth` module for bytecode size and gas cost
by using optimization techniques similar to those used in #7087 and
#7092.
The optimized public functions are listed in the below code snippet.
**The bytecode size of that code got reduced from 2480 bytes to 1200
bytes.**
```sway
fn main() {
let _ = std::auth::predicate_address();
let _ = std::auth::caller_addresses();
let _ = std::auth::caller_address();
}
```
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
This PR refines trait coherence checking to guarantee that there is only
one valid implementation for each trait. It introduces improved orphan
rules and more rigorous overlap checks to prevent conflicting trait
implementations. With these changes, the system now more reliably
enforces coherence, ensuring that traits are implemented uniquely, and
reducing potential ambiguities.
This approach mirrors Rust’s design by enforcing two distinct safety and
coherence checks on trait implementations:
**1. Orphan Rules Check**
The orphan rules require that for any trait implementation, either the
trait or the type must be defined within the current package. This
restriction prevents external packages from implementing foreign traits
for foreign types, which could otherwise lead to conflicting
implementations and ambiguities across different parts of a codebase.
Essentially, it helps maintain clear ownership and boundaries of trait
implementations.
**2. Overlap Impl Check**
The overlap impl check ensures that no two trait implementations can
apply to the same type in an ambiguous manner. If two implementations
could potentially match the same type, it would be unclear which one
should be used, leading to coherence issues. By enforcing that
implementations do not overlap, the system guarantees that trait
resolution is unambiguous and predictable.
Together, these checks promote a robust and maintainable system by
ensuring that trait implementations are both locally controlled (orphan
rules) and non-conflicting (overlap check).
The test suite has been updated to comply with the new rules. However,
there is one current limitation regarding arrays. For arrays, the
coherence checks have been relaxed to avoid the need for numerous
concrete implementations in the standard library for traits like `Eq`
and `PartialEq`. This decision was made because support for const
generics is expected soon, which will allow these traits to be
implemented more cleanly.
Closes issue https://github.com/FuelLabs/sway/issues/5892.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
This PR optimizes the `std::inputs` and `std::outputs` modules for
bytcode size and gas cost using the same optimization techinques like in
#7087.
The optimized public functions are listed in the below code snippet.
**The bytcode size of that code got reduced from 5688 bytes to 2544
bytes.**
```sway
fn main() {
let _ = std::tx::tx_witnesses_count();
let _ = std::inputs::input_count();
let _ = std::inputs::input_amount(0);
let _ = std::inputs::input_coin_owner(0);
let _ = std::inputs::input_predicate_data::<u64>(0);
let _ = std::inputs::input_asset_id(0);
let _ = std::inputs::input_witness_index(0);
let _ = std::inputs::input_predicate_length(0);
let _ = std::inputs::input_predicate(0);
let _ = std::inputs::input_predicate_data_length(0);
let _ = std::inputs::input_message_sender(0);
let _ = std::inputs::input_message_recipient(0);
let _ = std::inputs::input_message_nonce(0);
let _ = std::inputs::input_message_data_length(0);
let _ = std::inputs::input_message_data(0, 0);
let _ = std::outputs::output_count();
let _ = std::outputs::output_amount(0);
let _ = std::outputs::output_asset_id(0);
let _ = std::outputs::output_asset_to(0);
}
```
Additionally, the PR adds a new function
`std::outputs::output_asset_id_and_to` to efficiently retrieve the id
and the receiver of the output asset in a single call. Calling this
function is more performant that calling `output_asset_id` and
`output_asset_to` separately.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
This PR implement `Eq` and `PartialEq` for `Signature` and adds missing
`AbiEncode` and `AbiDecode` tests for the crypto module.
## 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 fixes the compiler panic in the case of a configurable
initializer that couldn't be const evaluated, like e.g:
```sway
fn non_const_evaluable() -> u64 {
asm() { fp: u64 }
}
configurable {
CONFIG: u64 = non_const_evaluable(),
}
```
Instead of a panic:
```
thread 'main' panicked at sway-core/src/ir_generation/compile.rs:320:14:
called `Result::unwrap()` on an `Err` value: NonConstantDeclValue { span: Span { src (ptr): 0x564e0b311600, source_id: Some(SourceId(6291595)), start: 1009, end: 1019, as_str(): "CONFIG" } }
```
the compiler now emits an error:
```
CONFIG: u64 = non_const_evaluable(),
^^^^^^ Could not evaluate initializer to a const declaration.
```
## Checklist
- [ ] I have linked to any relevant issues.
- [ ] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
This PR adds `#[error_type]` and `#[error]` attributes to the collection
of known attributes, as defined in the [ABI Errors
RFC](https://github.com/FuelLabs/sway-rfcs/blob/master/rfcs/0014-abi-errors.md).
Additionally, the PR updates the outdated documentation for _Attributes_
and _Keywords_.
Partially addresses #6765.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
Updates the fuels version to `0.71`, and the `fuel-vm` crates to
`0.59.2`
Also closes: https://github.com/FuelLabs/sway/issues/6976
Co-authored-by: z <zees-dev@users.noreply.github.com>
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
This PR adds a test consistency check that searches for redundant
`.gitignore` files in tests. They were spotted several times in code
reviews and removed. It was mentioned that having a lint for them would
spare us of these kind of findings in reviews.
## Checklist
- [ ] I have linked to any relevant issues.
- [ ] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
This PR removes the constraint on `u256` literals being only expressed
in hexadecimal.
The constraint has been removed and the code slightly refactored to
remove the unnecessary `radix` variable in the `lex_int_lit` function in
`token.rs`.
The corresponding error `LexErrorKind::U256NotInHex` has been removed
from the codebasen as well as the `should_fail` test looking to raise
this error.
The u256 testing suite has been augmented with additional tests to make
sure we can express u256 literals in decimal, binary and octal.
Closes#5456
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
---------
Co-authored-by: IGI-111 <igi-111@protonmail.com>
## Description
This PR is part of https://github.com/FuelLabs/sway/issues/6860.
It continues the implementation of more `std` library "traits" for
arrays.
It also fixes a small error when formatting "const generics
declarations".
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
This PR reimplements how `#[attribute]`s are parsed, defined, and
checked. It fixes the following issues we had with attributes:
- attributes were in general not checked for their expected and allowed
usage.
- when checked, checks were fixing particular reported issues and were
scattered through various compilation phases: lexing, parsing, and tree
conversion.
- when checked, reported errors in some cases had bugs and were
overalapping with other errors and warnings.
- attribute handling was not centralized, but rahter scattered throught
the whole code base, and mostly done at use sites.
For concrete examples of these issues, see the list of closed issues
below.
The PR:
- encapsulates the attributes handling within a single abstraction:
`Attributes`.
- assigns the following properties to every attribute:
- _target_: what kind of elements an attribute can annotate.
- _multiplicity_: if more then one attribute of the same kind can be
applied to an element.
- _arguments multiplicity_: a range defining how many arguments an
attribute can or must have.
- _arguments value expectation_: if attribute arguments are expected to
have values.
- validates those properties in a single place, during the
`convert_parse_tree`. Note that this means that modules with attribute
issues will now consistently not reach the type checking phase. This was
previously the case for some of the issues with attributes where custom
checks where done during the type checking phase. #6987 proposes to move
those checks after the tree conversion phase, allowing the continuation
of compilation.
- adds the `AttributeKind::Unknow` to preserve unknown attributes in the
typed tree.
- removes redundant code related to attributes: specific warnings and
errors, specialized parsing, repetitive and error-prone at use site
checks, etc.
- removes the unused `Doc` attribute.
The PR also introduces a new pattern in emitting errors. The
`attr_decls_to_attributes` function will always return `Attributes` even
if they have errors, because:
- we expect the compilation to continue even in the case of errors.
- we expect those errors to be ignored if a valid `#[cfg]` attribute
among those evaluates to false.
- we expect them to be emitted with eventual other errors, or alone, at
the end of the tree conversion of the annotated element.
For more details, see the comment on `attr_decls_to_attributes` and
`cfg_eval`.
Closes#6880; closes#6913; closes#6914; closes#6915; closes#6916;
closes#6917; closes#6918; closes#6931; closes#6981; closes#6983;
closes#6984; closes#6985.
## Breaking changes
Strictly seen, this PR can cause breaking changes, but only in the case
of invalid existing attribute usage. We treat those breaking changes as
bug fixes in the compiler and, thus, do not have them behind a feature
flag.
E.g., this kind of code was possible before, but will now emit and
error:
```sway
#[storage(read, write, read, write)]
struct Struct {}
```
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
Fixes#6846 .
The dependency graph is currently represented as a tree structure in the
field `Root::external_packages` field. Since the dependency graph is in
general a dag, there is a potential exponential blowup in representing
it as a tree structure, so we would like to instead represent it using a
linear structure.
In order to create a linear structure we will need to move the
dependency graph out of the `Root` struct, so that `Root` objects can be
inserted into the dependency graph without causing issues with Rust.
This PR is a step towards that goal in that moves almost all the code
that accesses `external_packages` from `impl Root` to `impl Namespace`.
In particular:
- The functions that perform imports have been moved. This also allows
some minor simplifications of the code, since imports are only ever
performed with the destination being the current module.
- The module visibility check has been moved, and simplified.
- Various helper functions have been moved, and simplified.
- `module_mut_from_absolute_path` has been moved, and mutable access to
external modules has been eliminated.
`module_from_absolute_path` has not yet been moved, since this function
is used by `sway-lsp`, which does not have access to a `Namespace`
object. This will be fixed as part of the datastructure change.
Additionally, a few other refactorings have taken place:
- The `ResolvedDeclaration` type has been moved to its own file.
- `Root` has been renamed to `Package`, with variables and fields
renamed accordingly.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
Codec needs to be imported to all libraries in the std lib which define
new types, or else they cannot be used in Abi functions or logged.
## 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: K1-R1 <77465250+K1-R1@users.noreply.github.com>
## Description
Implements dereferencing as LHS in reassignments for projections.
With this PR we will support:
- `(*array)[0] = 1`
- `(*tuple).0 = 1`
- `(*struct).a = 1`
This also includes support for nested references.
Fixes#6397
There is some progress in #5063
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
Fixes#6119 .
Currently, items implicitly imported from the standard library preludes
reside in the same namespace as star imports from non-prelude sources.
This means that if a star import imports a name that clashes with a name
from a prelude, then using that name in the importing module causes an
error.
This PR separates the prelude imports into a different namespace, and
allows star imports to shadow prelude imports.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
---------
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
## Description
This is part of https://github.com/FuelLabs/sway/issues/6860.
This completes abi encoding for arrays. Allowing arrays of any size as
inputs and outputs in predicates/scripts/contracts.
This PR also allows arrays to be initialized with "const generics" such
as:
```sway
#[cfg(experimental_const_generics = true)]
impl<T, const N: u64> AbiDecode for [T; N]
where
T: AbiDecode,
{
fn abi_decode(ref mut buffer: BufferReader) -> [T; N] {
let first: T = buffer.decode::<T>();
let mut array = [first; N]; // <-------------------- This can used now
...
array
}
}
````
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
This PR improves snapshot testing by moving the snapshot testing
infrastructure from the separate `tests` project inside of the
`e2e_vm_tests`.
This solves the following issues:
- double test execution on CI. Snapshot tests were executed twice on the
CI, once as as part of `cargo_run_e2e_tests` and once as a part of
`cargo_test_workspace`.
- double compilation. When running `e2e_vm_tests`, snapshot tests were
executed as a separate process. In the recent issue with recompiling
crates, this has caused the crates to be recompiled twice, starting from
the `ring` crate.
- access to `reduced_std_libs`. Snapshot tests also need access to
`reduced_std_libs`. Until now, they dependent only on `core` and
full-blown `std`, but now they also depend on `sway-lib-std-core` which
is generated when `e2e_vm_tests` are executed, but not when only
snapshot tests were executed without the `e2e_vm_tests`.
Additionally, the PR:
- adds the `--kind/-k` CLI parameter to the `e2e_vm_tests` allowing to
filter out which tests should be run. E.g.:
```
--kind e2e
--kind ir e2e snapshot
```
Not specifying `--kind` runs all the tests.
- removes the obsolete `exclude_core` CLI parameter from the
`e2e_vm_tests`.
## 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
This PR promotes the following experimental features to standard ones:
- #6701
- #6883
- #6994
- #7006
Additionally, the PR stenghtens the migration infrastructure by checking
some additional cases in selecting corresponding typed elements in
desugared code which were not checked before.
Closes#6701.
Closes#6883.
Closes#6994.
Closes#7006.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
Merges the two libraries. They were initially separate to separate the
core logic and fuel vm specific functionality, but that separation is no
longer maintained so having a merged library is better.
Closes#6708
## Checklist
- [ ] I have linked to any relevant issues.
- [ ] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [ ] I have requested a review from the relevant team or maintainers.
---------
Co-authored-by: Sophie <47993817+sdankel@users.noreply.github.com>
Co-authored-by: Igor Rončević <ironcev@hotmail.com>
## Description
When running tests in contracts with the fallback function, we get an
error with the `__log` intrinsic. The issue is that we needlessly
compile the fallback function twice. And in some cases (numeric decay),
the `__log` argument would return a `TypeId` that was not collected in
the `collect_metadata` phase.
```
29 |
30 | use std::call_frames::*;
31 | __log(3);
| ^^^^^^^^ Internal compiler error: Unable to determine ID for log instance.
Please file an issue on the repository and include the code that triggered this error.
32 | __log(called_method());
33 | __log("double_value");
|
____
```
This was never caught because we only compile `sdk-harness` tests, we
never run their unit tests in the CI. Which this PR is also doing.
## Checklist
- [ ] I have linked to any relevant issues.
- [ ] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
This PR adds migration step for merging `core` and `std` libraries, as
explained in the Breaking Changes chapter of #7006.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] 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 adds arithmetic test cases to ensure `u8`, `u16`, `u32`, `u64`,
`U128`, and `u256` behave as expected in normal conditions, when
overflow is disabled, when unsafe math is enabled, and edge cases.
Previously, the modulo and square root functions of `U128` would not
revert, even if unsafe math is enabled.
The following test cases are new for inline tests:
### `u8`
- Add
- Revert Add on overflow
- Revert on unsafe math on overflow
- Binary log of zero fails on overflow disabled
- Binary log of zero returns zero on unsafe math
- Divide
- Divide behavior on unsafe math
- Divide by zero reverts
- Log still reverts when overflow enabled
- Log behavior on unsafe math enabled
- Log parity with Rust tests
- Modulo zero still reverts with overflow enabled
- Multiply
- Multiply overflow still reverts on unsafe math enabled
- Pow still reverts on unsafe math enabled
- Root behavior the same on overflow enabled
- Root behavior the same on unsafe math enabled
- 0th root will fail
- Subtract
- Subtract underflow still reverts with unsafe math enabled
### `u16`
- Add
- Revert Add on overflow
- Revert on unsafe math on overflow
- Binary log of zero fails on overflow disabled
- Binary log of zero returns zero on unsafe math
- Divide
- Divide behavior on unsafe math
- Divide by zero reverts
- Log still reverts when overflow enabled
- Log behavior on unsafe math enabled
- Log parity with Rust tests
- Modulo zero still reverts with overflow enabled
- Multiply
- Multiply overflow still reverts on unsafe math enabled
- Pow still reverts on unsafe math enabled
- Root behavior the same on overflow enabled
- Root behavior the same on unsafe math enabled
- 0th root will fail
- Subtract
- Subtract underflow still reverts with unsafe math enabled
### `u32`
- Add
- Revert Add on overflow
- Revert on unsafe math on overflow
- Binary log of zero fails on overflow disabled
- Binary log of zero returns zero on unsafe math
- Divide
- Divide behavior on unsafe math
- Divide by zero reverts
- Log still reverts when overflow enabled
- Log behavior on unsafe math enabled
- Log parity with Rust tests
- Modulo zero still reverts with overflow enabled
- Multiply
- Multiply overflow still reverts on unsafe math enabled
- Pow still reverts on unsafe math enabled
- Root behavior the same on overflow enabled
- Root behavior the same on unsafe math enabled
- 0th root will fail
- Subtract
- Subtract underflow still reverts with unsafe math enabled
### `u64`
- Add
- Revert Add on overflow
- Revert on unsafe math on overflow
- Binary log of zero fails on overflow disabled
- Binary log of zero returns zero on unsafe math
- Divide
- Divide behavior on unsafe math
- Divide by zero reverts
- Log still reverts when overflow enabled
- Log behavior on unsafe math enabled
- Log parity with Rust tests
- Modulo zero still reverts with overflow enabled
- Multiply
- Multiply overflow still reverts on unsafe math enabled
- Pow still reverts on unsafe math enabled
- Root behavior the same on overflow enabled
- Root behavior the same on unsafe math enabled
- 0th root will fail
- Subtract
- Subtract underflow still reverts with unsafe math enabled
### `U128`
- Revert Add on overflow
- Revert on unsafe math on overflow
- Binary log of zero fails on overflow disabled
- Binary log of zero returns zero on unsafe math
- Divide behavior on unsafe math
- Log still reverts when overflow enabled
- Log behavior on unsafe math enabled
- Log parity with Rust tests
- Modulo zero still reverts with overflow enabled
- Multiply overflow still reverts on unsafe math enabled
- Pow still reverts on unsafe math enabled
- Root behavior the same on overflow enabled
- Root behavior the same on unsafe math enabled
- Subtract underflow still reverts with unsafe math enabled
### `u256`
- Add
- Revert Add on overflow
- Revert on unsafe math on overflow
- Binary log of zero fails on overflow disabled
- Binary log of zero returns zero on unsafe math
- Divide
- Divide behavior on unsafe math
- Divide by zero reverts
- Log still reverts when overflow enabled
- Log behavior on unsafe math enabled
- Log parity with Rust tests
- Modulo zero still reverts with overflow enabled
- Multiply
- Multiply overflow still reverts on unsafe math enabled
- Pow still reverts on unsafe math enabled
- Root behavior the same on overflow enabled
- Root behavior the same on unsafe math enabled
- Subtract
- Subtract underflow still reverts with unsafe math enabled
## 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: K1-R1 <77465250+K1-R1@users.noreply.github.com>
## Description
This PR is part of https://github.com/FuelLabs/sway/issues/6860.
It implements "impl traits" for "const generics", which means syntax
such as:
```sway
trait A {
fn my_len(self) -> u64;
}
impl<T, const N: u64> A for [T; N] {
fn my_len(self) -> u64 {
N
}
}
```
This also opens the space for simplifying our current implementation of
`AbiEncode` for arrays. Today we implement for each size, which limits
us to a specific size. With this one can have just one "impl item", and
support arrays of arbitrary size.
Both implementations will coexist in `codec.sw` until we stabilize
"const generics".
```sway
#[cfg(experimental_const_generics = true)]
impl<T, const N: u64> AbiEncode for [T; N]
where
T: AbiEncode,
{
fn abi_encode(self, buffer: Buffer) -> Buffer {
....
}
}
#[cfg(experimental_const_generics = false)]
impl<T> AbiEncode for [T; 0]
where
T: AbiEncode,
{
fn abi_encode(self, buffer: Buffer) -> Buffer {
...
}
}
```
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
Fixes#6329 .
During insertion of `impl`s into the trait map we used to forget to
check for alias types, which meant that it was possible to have multiple
implementations of a trait for the same type, one for the original type
and one for the alias.
#6626 fixed this bug, but the error message was unhelpful in that it
reported the error on the original type without mentioning the alias.
This PR improves the error message, and also improves the error message
for aliased types when they contain multiple declarations of the same
member.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
---------
Co-authored-by: IGI-111 <igi-111@protonmail.com>
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
`impl From<Bytes> for b256` has been removed and replaced with `impl
TryFrom<Bytes> for b256` increasing saftey when converting between the
two types. `impl Into<Bytes> for b256` and `impl TryInto<b256> for
Bytes` have also been added.
This PR breaks the following implementation:
```sway
let mut my_bytes = Bytes::new();
my_bytes.push(1u8);
let result: b256 = b256::from(my_bytes);
```
The implementation should now be:
```sway
let mut my_bytes = Bytes::new();
my_bytes.push(1u8);
// Option 1
let result_1: Option<b256> = b256::try_from(my_bytes);
// Option 2
let result_2 = my_bytes.try_into();
```
Closes#6994.
## 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: Igor Rončević <ironcev@hotmail.com>
## Description
Fully resolves trait constraints call paths. To be used in trait
coherence work.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
handle u32 and u16 subtract underflow manually.
Mirror u8 impl's use of u64 conversion for u16 and u32.
Add additional u8 test.
Closes#6653.
Closes#6666.
## 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: SwayStar123 <46050679+SwayStar123@users.noreply.github.com>
## Description
- Added support for viewing emitted logs when making a transaction using
forc-call
- Added `show_receipts` param (default-false) - so we can optionally
prnt out all receipts
- The CLI output becomes too long for a call with multiple receipts;
this is a minor UI enhancement
Addresses https://github.com/FuelLabs/sway/issues/6887
## Example usage/output
```sway
script;
struct ExampleParams {
test_val: u32,
test_str: str,
test_tuple: (u32, u64),
}
fn main() -> u64 {
log("hiiii");
log(123);
log(ExampleParams { test_val: 5, test_str: "hello world", test_tuple: (1,2) });
5
}
```
<img width="986" alt="image"
src="https://github.com/user-attachments/assets/3725ff17-29c9-43d7-98cc-4cacfc213ecb"
/>
## 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] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [ ] I have requested a review from the relevant team or maintainers.
---------
Co-authored-by: z <zees-dev@users.noreply.github.com>
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
Co-authored-by: kayagokalp <kayagokalp123@gmail.com>
## Description
This PR is part of https://github.com/FuelLabs/sway/issues/5110. It
fixes a problem that improves the usability of slices.
When a method is returned from the "method resolution algorithm", if any
generic is involved, it is returned as its generic form. So for example,
if a method `len` is called on `Vec<u8>`, we return something like `fn
len(self: Vec<T>)`.
Later we monomorphize `T` into `u8`. To do that we run a "pattern match"
to realize that we need to replace `T` with `u8`.
In this case, the bug was that we were not considering that some
primitive types have "implicit type parameters".
This was found whilst creating more tests for
https://github.com/FuelLabs/sway/pull/6933, because I was not able to
call the `len` method defined for slices as:
```sway
impl<T> &[T] {
pub fn len(self) -> u64 {
...
}
}
```
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
Moves dev dependencies to the workspace Cargo.toml for consistent
versions in tests.
Inspired by https://github.com/FuelLabs/sway/pull/6955
## Checklist
- [ ] I have linked to any relevant issues.
- [ ] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [ ] I have requested a review from the relevant team or maintainers.
## Description
Adds an iterator to allow for loops over bytes
## 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: Cameron Carstens <bitzoic.eth@gmail.com>
## Description
This PR allows `LDC` opcode in predicates. Historically, it was not
allowed in the FuelVM, but this restriction is removed and we are
removing it now from Sway as well.
## Checklist
- [ ] I have linked to any relevant issues.
- [ ] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
Adds the conversion helper for U128
## 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
The `bldd` opcode was not covered in the `Op::parse_opcode()` which
resulted in `Unknown opcode: "bldd"` error.
The remaining part of the `bldd` opcode integration chain is already
implemented in #6254.
## Checklist
- [x] I have linked to any relevant issues.
- [ ] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
Add support for the `#[deprecated]` attribute to functions, enums,
struct items, enum variants and propagate deprecation check exhaustively
throughout expressions variants.
Partially addresses #6942.
Support for deprecating traits, abis and the methods thereof in their
definitions is still missing, as well as scrutinees and storage fields.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
The ECAL opcode is supported in `fuel-vm` to extend the capabilities of
the VM.
Users can implement rust code to interop with the VM using the ECAL
opcode.
This PR introduces support for the opcode in the sway repo - such that
sway assembly can be successfully compiled with the ECAL opcode.
Examples of how to utilize the `ECAL` opcode can be seen here:
9478991db1/fuel-vm/examples/external.rs (L51)
- Closes https://github.com/FuelLabs/sway/issues/5239
- Added an e2e test to validate compilation of ecall opcode in sway
assembly.
## Checklist
- [x] I have linked to any relevant issues.
- [ ] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [ ] I have requested a review from the relevant team or maintainers.
---------
Co-authored-by: z <zees-dev@users.noreply.github.com>
## Description
Shows that #6387 has been fixed.
This PR adds a few tests of variable initializers that involve type
Never. In this case the variable's type ascription should be used
instead of the initializer's type.
No changes have been made to the compiler, since the problem that was
originally reported was fixed by #6911.
## 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.
