## Description
This PR reimplements how `#[attribute]`s are parsed, defined, and
checked. It fixes the following issues we had with attributes:
- attributes were in general not checked for their expected and allowed
usage.
- when checked, checks were fixing particular reported issues and were
scattered through various compilation phases: lexing, parsing, and tree
conversion.
- when checked, reported errors in some cases had bugs and were
overalapping with other errors and warnings.
- attribute handling was not centralized, but rahter scattered throught
the whole code base, and mostly done at use sites.
For concrete examples of these issues, see the list of closed issues
below.
The PR:
- encapsulates the attributes handling within a single abstraction:
`Attributes`.
- assigns the following properties to every attribute:
- _target_: what kind of elements an attribute can annotate.
- _multiplicity_: if more then one attribute of the same kind can be
applied to an element.
- _arguments multiplicity_: a range defining how many arguments an
attribute can or must have.
- _arguments value expectation_: if attribute arguments are expected to
have values.
- validates those properties in a single place, during the
`convert_parse_tree`. Note that this means that modules with attribute
issues will now consistently not reach the type checking phase. This was
previously the case for some of the issues with attributes where custom
checks where done during the type checking phase. #6987 proposes to move
those checks after the tree conversion phase, allowing the continuation
of compilation.
- adds the `AttributeKind::Unknow` to preserve unknown attributes in the
typed tree.
- removes redundant code related to attributes: specific warnings and
errors, specialized parsing, repetitive and error-prone at use site
checks, etc.
- removes the unused `Doc` attribute.
The PR also introduces a new pattern in emitting errors. The
`attr_decls_to_attributes` function will always return `Attributes` even
if they have errors, because:
- we expect the compilation to continue even in the case of errors.
- we expect those errors to be ignored if a valid `#[cfg]` attribute
among those evaluates to false.
- we expect them to be emitted with eventual other errors, or alone, at
the end of the tree conversion of the annotated element.
For more details, see the comment on `attr_decls_to_attributes` and
`cfg_eval`.
Closes#6880; closes#6913; closes#6914; closes#6915; closes#6916;
closes#6917; closes#6918; closes#6931; closes#6981; closes#6983;
closes#6984; closes#6985.
## Breaking changes
Strictly seen, this PR can cause breaking changes, but only in the case
of invalid existing attribute usage. We treat those breaking changes as
bug fixes in the compiler and, thus, do not have them behind a feature
flag.
E.g., this kind of code was possible before, but will now emit and
error:
```sway
#[storage(read, write, read, write)]
struct Struct {}
```
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
This PR promotes the following experimental features to standard ones:
- #6701
- #6883
- #6994
- #7006
Additionally, the PR stenghtens the migration infrastructure by checking
some additional cases in selecting corresponding typed elements in
desugared code which were not checked before.
Closes#6701.
Closes#6883.
Closes#6994.
Closes#7006.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
Merges the two libraries. They were initially separate to separate the
core logic and fuel vm specific functionality, but that separation is no
longer maintained so having a merged library is better.
Closes#6708
## Checklist
- [ ] I have linked to any relevant issues.
- [ ] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [ ] I have requested a review from the relevant team or maintainers.
---------
Co-authored-by: Sophie <47993817+sdankel@users.noreply.github.com>
Co-authored-by: Igor Rončević <ironcev@hotmail.com>
## Description
fixed 3 typos
## Checklist
- [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 done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
This PR is part of https://github.com/FuelLabs/sway/issues/5110 and
introduces two new intrinsic: `__slice` and `__elem_at`.
`__slice` allows the creation of slices by slicing arrays or other
slices. Whilst `__elem_at` returns a reference to an item inside the
slice or the array.
## Out of bounds checks
These intrinsic will not generate any runtime checks, these must be done
manually, when and where appropriate; but they do a complete static
analysis of all indices, to avoid runtime buffer overflows, when
possible.
That means that at runtime, it is possible to do a buffer overflow when
reading/writing, which is an "undefined behaviour" as to what will
happen.
## Empty Array
This PR also solves a problem with empty arrays. Before empty arrays
such as `let a = []` were being type-checked as `[Never; 0]`, which
means that any code after them was being marked as dead.
Now we correctly type check them as `[Unknown; 0]` and return a more
friendly error.
```
4 |
5 | // Empty array
6 | let a = [];
| ^^ Type must be known at this point
7 | }
|
____
```
## Check of constants inside fns
This PR also solves a problem with not checking `const` expressions
inside `fns`. We, for example, do not allow slices in constants, but we
were only checking globals. Now we check constants also inside
functions, methods etc...
## Small improvements for our e2e
We can now `dbg` inside our e2e harness and get results like the ones
below. One needs to include the lib `test/src/e2e_vm_tests/utils` and
cal `something.dbg()` or `something.dbgln()`. There is no magic, and
structs/enums will need to manually implement the `Dbg` trait.
This is only to facilitate the debugging of our e2e tests.
## Checklist
- [ ] I have linked to any relevant issues.
- [ ] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [ ] I have requested a review from the relevant team or maintainers.
Update
## Description
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
Co-authored-by: IGI-111 <igi-111@protonmail.com>
## Description
With this change storage keys will have a hash based on:
`sha256("storage::<storage_namespace_name1>::<storage_namespace_name2>.<storage_field_name>"`
or a given key.
A key can be provided by using the `in` keyword in a storage field as
such:
```
storage {
a in 0x02dac99c283f16bc91b74f6942db7f012699a2ad51272b15207b9cc14a70dbae: u64
}
```
Or by using a const expression:
```
const C1 = 0x02dac99c283f16bc91b74f6942db7f012699a2ad51272b15207b9cc14a70dbae;
storage {
a in C1: u64
}
```
StorageKey.field_id is now based on:
`sha256("storage::<storage_namespace_name1>::<storage_namespace_name2>.<storage_field_name>.<struct_field_name1>.<struct_field_name2>")`
Nested storage namespaces such as the following are now supported.
```
storage {
my_namespace1 {
my_namespace2 {
b:u64 = 1,
}
}
}
```
A deprecated warning is now thrown when the attribute `#[namespace(ns)]`
is used.
A warning is thrown when storage fields use the same storage slot key.
The warning looks like this:
```
Two storage fields are using the same storage key.
First field: storage::ns1.f3
Second field: storage::ns2.f4
Key: 5F4C20CE4BD128E5393A4C2B82007DAC795FA0006D01ACF8DB4C42632BC680CA
```
This PR does not include yet the necessary documentation updates.
Created dev-rel documentation request:
https://github.com/FuelLabs/devrel-requests/issues/14
## 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).
- [x] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
---------
Co-authored-by: IGI-111 <igi-111@protonmail.com>
## Description
These projects are used as templates in `forc template` and having the
lock files as part of the template could cause issues. The lock file
should be generated on the fly by forc.
## 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
Introduces the following functions to be implemented:
- `zero()`
- `is_zero()`
This falls inline with what we see in [Rust's Zero
Trait](https://docs.rs/num/latest/num/traits/trait.Zero.html), making
the language feel and look more like Rust.
This PR also deprecates the following:
- `ZERO_B256` -> `b256::zero()`
- `ZERO_U256` -> `u256::zero()`
To define a `u256` or `b256` zero address, the following should be used:
```sway
let zero_b256 = b256::zero();
let zero_u256 = u256::zero();
```
A common use of the `ZERO_B256` was to define the zero addresses and
contract id`:
```sway
let zero_address = Address::from(ZERO_B256);
let zero_contract = ContractId::from(ZERO_B25);
```
The following is now possible:
```sway
let zero_address = Address::zero();
let zero_contract = ContractId::zero();
```
The following types now implement the `Zero` trait:
- `u8`
- `u16`
- `u32`
- `u64`
- `u256`
- `b256`
- `SubId`
- `AssetId`
- `ContractId`
- `Address`
- `EvmAddress`
- `U128`
- `B512`
Closes#5830
## 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: K1-R1 <77465250+K1-R1@users.noreply.github.com>
## Description
Adds a CI check for typos and fixes all* typos in code, comments, and
docs.
*found by [typos-cli](https://github.com/crate-ci/typos)
`typos` doesn't catch everything, but it seems to work better than
codespell and cargo-spellcheck (fewer false positives).
## 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
Previously the Sway book did not have any sections on Sway-Libs,
Sway-Standards, or Sway-Applications and was sparsely mentioned.
Sections for each repository have been added with a brief overview of
what they contain. Links to any app, standard, or library have also been
provided.
Any use of the sway-libs repository has been replaced with the
[Sway-Libs book](https://fuellabs.github.io/sway-libs/book/index.html).
This should eventually be replaced with a doc hub link when it has been
integrated and the same for Sway-Apps and Sway-Libs.
Closes#5780
## Checklist
- [x] I have linked to any relevant issues.
- [ ] 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 implements dereferencing in reassignment targets, as defined in
[references](https://github.com/FuelLabs/sway-rfcs/blob/ironcev/amend-references/files/0010-references.sw).
The overall effort related to references is tracked in
https://github.com/FuelLabs/sway/issues/5063.
Up to now, it was only possible to read the values references refer to.
This PR allows values to be written over `&mut` references. In other
words, any `*<expression that results in &mut>`is now an l-values and
can be used in left-hand sides (LHS) of assignments. In most of the
cases, the `<expression>` will very likely be just a reference variable,
but any expression that results in `&mut` is allowed and supported.
E.g.;
```Sway
*mut_ref_to_u64 = 42;
*if condition { &mut x } else { &mut y } = 42;
*max_mut(&mut x, &mut y) = 42;
```
Additionally, the PR:
- fixes#5736 by properly replacing decls in reassignment LHSs.
- fixes#5737 by properly substituting types in reassignment LHSs.
- fixes#5920 by properly connecting expressions in array indices to the
DCA graph.
- fixes#5922 by type-cheking the array indices in reassignment LHSs and
forcing them to be `u64`.
- improves misplaced and misleading error messages when assigning to
constants and other items (see demo below).
- improves error message when assigning to immutable variables by
pointing to variable declaration.
- improves error message when expression cannot be assigned to by
pointing to the problematic part of the expression. Since Sway is more
restrictive here then Rust, the restrictions, without being explained,
could cause confusion. That's why special attention was given to point
to the exact issue and explain what is actually supported in Sway (see
demo below).
- reduces number of expected warnings in references E2E tests that were
previously set high because of DCA issues that are fixed in the
meantime.
The PR also brings additional analysis and checks to IR optimizations.
Among other things, it explicitly points out the cases in which a
potential usage of a symbol cannot be deterministically confirmed or
denied. In this PR properly reacting for such cases is done in some
optimizations. Rolling it out fully will be done in a follow up PR
#5924. More advanced escape analysis will be done later on, as a part of
allocating values on the heap in case of referencing.
This PR implements only dereferencing in LHS. Support for referenced
elements in the element based access (without dereferencing) will be
done in a separate step as an ongoing work on implementing #5063.
Closes#5736, #5737, #5920, #5922.
## Demo
Before:
After:
Expression cannot be assigned to:
## 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 sets the "new encoding" (from now on will be called "encoding
v1") as the default. We can still disable it using `no_encoding_v1`,
which switches back to "encoding v0".
Actions that needs to be done after this being merged will exist in
https://github.com/FuelLabs/sway/issues/5727
New features
- ABI Super traits;
- AbiEncode buffer dynamic sizing;
Bugs Fixed
- `ContractCall` intrinsic interaction effect was not set correctly;
Fixing warnings and error messages
- Better error message when core-lib is not available for
scripts/contracts/predicates;
- Better error message when main inputs/outputs are unknown or error
types;
- Better error message when main inputs/outputs do not implement
AbiEncode/AbiDecode;
- Don't warn impurity attributes on the "__entry" fn;
- Don't warn CEI on the "__entry" fn. Our CEI analysis, currently, does
not recognize `Never`. This means it does not realize it is impossible
to call two contract functions;
Test Disabled (needs to be enabled again in the future)
- should_pass/language/name_resolution_after_monomorphization
- should_pass/language/shadowing/shadowed_glob_imports
- should_pass/language/name_resolution_inside_intrinsics
- sdk-harness/external_proxy test is not working. I am assuming it is
the LDC bug that is already fixed on version 0.25. What is happening is
that the literal "double_value" has the correct length, but some random
data. Which makes the method selector fails. Only after we call LDC. The
proxy contract is working.
Test generating more warnings than before
- should_pass/dca/contract/superabi_contract_calls
What happens here is that when we implement a trait for `Contract`, we
actually generate two functions: one prefixed `__contract_entry` that is
called by the method selector; and another one normal, that can be
called freely. So, if the trait method is never called manually, it is
marked as dead.
- should_pass/dca/contract/abi_fn_params
I actually think the new warning is correct and nothing here needs to be
done.
Test with fewer warnings than before
- should_pass/dca/unused_fields
auto-impl is making all fields being used. so no dead code warnings are
being generated. We need to fix this.
Changes to std-lib
- Functions that return data about call context changed the semantic.
`first_param` and `second_param` return the value as the VM sees them.
We now have `called_method` and `called_args`. This means that we can
change the protocol later and still keep these four functions always
working and with meaningful names.
-
- predicate_data also was updated to use encoding v1 protocol.
ICE
- increase_buffer_if_needed implementation is a little bit strange
because does not work as a method inside `Buffer`. For some reason, it
is generating an ICE. I need to create an issue so we can fix, and
improve the implementation here.
- `Buffer` used by AbiEncode needs a `push_bytes` so we can be more
efficient when encoding Bytes and others.
## 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
There are currently multiple functions for the same functionality:
Transfer:
- `transfer()`
- `force_transfer_to_contract()`
- `transfer_to_address()`
Mint:
- `mint()`
- `mint_to()`
- `mint_to_contract()`
- `mint_to_address()`
This be reduced to just `transfer()`, `mint()`, `mint_to()`. Specific
functions for separately minting and transferring to contracts and
addresses are legacy code left over from before the `Identity` type was
introduced and now only adds additional complexity.
## Changes:
- `force_transfer_to_contract()` is now private
- `transfer_to_address()` is now private
- `mint_to_contract()` removed
- `mint_to_address()` removed
- Removed newlines in inline docs for better `forc doc` compatibility
- Updated `burn()` inline docs
## Breaking Changes:
- `force_transfer_to_contract()` is now private
- `transfer_to_address()` is now private
- `mint_to_contract()` removed
- `mint_to_address()` removed
## Closes
- Closes#5773
## 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: K1-R1 <77465250+K1-R1@users.noreply.github.com>
## Description
The Base asset ID is no longer a constant. It is now stored in memory
and retrieved using the `GM` opcode. More information can be found
[here](https://github.com/FuelLabs/fuel-specs/blob/master/src/fuel-vm/instruction-set.md#gm-get-metadata).
## Breaking Changes
- The `BASE_ASSET_ID` constant has been removed.
- `AssetId::base_asset_id()` is now `AssetId::base()`.
## 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
Paths have changed in Sway-Standards and Sway-Libs resulting in dead
links.
Required for any other PRs to have passing CI.
## Checklist
- [ ] I have linked to any relevant issues.
- [ ] 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
Merges the staging branch into master from the following PRs:
https://github.com/FuelLabs/sway/pull/5640https://github.com/FuelLabs/sway/pull/5630https://github.com/FuelLabs/sway/pull/5621https://github.com/FuelLabs/sway/pull/5613
## 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: IGI-111 <igi-111@protonmail.com>
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
## Description
Add a `#[namespace(my_namespace)]` annotation to allow developers to
avoid storage slot collisions when loading contract code using LDC.
Fixes#5490
## 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 PR makes struct fields private by default and introduces explicit
public struct fields:
```
pub struct Struct {
pub public_field: u8,
private_field: u8,
}
```
Private fields can be accessed only withing the module in which their
struct is declared.
Error messages are properly orchestrated so that no conflicting or
duplicated messages are emitted. Since the change is a breaking change,
relevant suggestion on how to fix the particular issue are given.
To avoid an abrupt breaking change, the errors are temporarily turned
into warnings. These warnings will become errors in the upcoming
versions of Sway. The demo section below demonstrate how the errors will
look like, and how a one warning equivalent looks now.
Standard library structs like `Vec` or `String`, are adapted where
needed by adding the `pub` keyword to the fields that are accessed
outside of the struct declaration module. Some of these fields should
very likely remain public, but some, like e.g., `RawBytes::ptr` or
`Vec::buf` should be private. Adjusting the standard library to properly
utilize private fields is out of scope of this PR and will be done
separately. I expect breaking changes in the STD once we start modeling
structs keeping encapsulation in mind.
In addition, the PR:
- migrates
[annotate_snippets](https://github.com/rust-lang/annotate-snippets-rs)
crate to its latest version (breaking changes)
- removes a redundant non-existing field error and orchestrates
non-existing field error with privacy errors
- replaces an invalid and misleading error when accessing fields on
storage elements that are not structs
Closes#4692.
## Known limitations
There is an issue in displaying multi-line code snippets, which is
independent of these changes, but wasn't apparent before. The issue is
visible in the demo section below, where the struct bodies are sometimes
not fully shown, and they should be. This issue is reported in #5499 and
will be solved in a separate PR.
## Demo (an excerpt 😄)
### Private struct field is inaccessible
### Struct cannot be instantiated
### Struct pattern must ignore inaccessible private fields
### Struct pattern has missing fields
### Errors temporarily turned into warnings
## 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
Change `From` conversion trait into the expected `From`/`Into` rust-like
trait pair and `TryFrom` into a `TryFrom`/`TryInto` pair.
## 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.
- [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: Marcos Henrich <marcoshenrich@gmail.com>
Co-authored-by: João Matos <joao@tritao.eu>
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
Bumps repo to 0.49.0, made this a major one after some thought as we
longer support beta-4 as tooling with this release.
Also ran `cargo update` as this is a breaking change
---------
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
We currently use the following terminology in the standard library when
discussing native assets on Fuel:
- Asset
- Coin
- Token
This can be incredibly confusing for new developers. A naming convention
that is consistent across the standard library, docs, and examples is
critical for clarity.
In the following PR I formalize the use of the words "Asset" and "Coin".
- An "Asset" is a Native Asset on Fuel and has the associated `AssetId`
type. Assets are distinguishable from one another.
- A "Coin" represents a singular unit of an Asset. Coins of the same
Asset are not distinguishable from one another.
The changes made reflect the distinction that Fuel does not use tokens
like other ecosystems such as Ethereum and uses Native Assets with a
UTXO design instead.
The Asset and Coin terminology is also consistent the fuel-vm's input
and outputs types. This is already seen in the `input.sw` file with the
`Input::Coin` enum and `output.sw`'s `Output::Coin` enum in the standard
library respectively.
## Breaking Changes
Imports using the `token` import should now use the `asset` import.
Before:
```sway
use std::token::mint;
```
After:
```sway
use std::asset::mint;
```
## 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
Closes#5321
Added an assertion that mirrors the existing `assert_eq(x, y)` function.
The `assert_ne(x, y)` function asserts that the two passed values are
not equal. This removes the need for the workaround `assert(x != y)`.
Documentation was updated in all areas that `assert_eq()` is referenced.
Tests were created similarly to the `assert_eq()` tests. The function
was also added to
[`prelude.sw`](9ee4b7a85d/sway-lib-std/src/prelude.sw (L20)).
## 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.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [ ] I have requested a review from the relevant team or maintainers.
## Description
Closes https://github.com/FuelLabs/fuel-debugger/issues/15
Moves https://github.com/FuelLabs/fuel-debugger into a forc plugin.
## 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: Hannes Karppila <hannes.karppila@gmail.com>
## Description
This PR is part of https://github.com/FuelLabs/sway/pull/4794. It is the
minimum implementation for deprecation. Pretty much only what was needed
for deprecating `U256`.
It also minimally implements `#[allow(deprecated)]`.
## 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 to the Sway book a new entry for associated types explaining what
they are and how they can be used.
Adds associated types to reference docs.
## Checklist
- [ ] I have linked to any relevant issues.
- [ ] 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).
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
---------
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
This PR is part of https://github.com/FuelLabs/sway/pull/4794 and
updates documentation for `u256` and improves test for edge cases.
Code also prints more info when tests run in `verbose` mode.
## 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: IGI-111 <igi-111@protonmail.com>
