## Description
This PR improves fix a problem when a type cannot be auto-impled and
improve error messages for this case.
This can be seen on `tests/types/contracts/type_inside_enum` in the Rust
SDK repo.
```
Running `target/debug/forc build --path /home/xunilrj/github/fuels-rs/packages/fuels --experimental-new-encoding`
thread 'main' panicked at sway-ir/src/constant.rs:172:14:
Enums are aggregates.
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
Given that this PR also improve implementation of arrays for `AbiEncode`
and `AbiDecode`, the entry function is actually generated. But in case
of error, it will fail like:
```
error
--> /home/xunilrj/.forc/git/checkouts/std-9be0d6062747ea7/5645f10143243e1fd64a55002cd5c09730636ece/sway-lib-core/src/codec.sw:2192:8
|
2190 |
2191 | pub trait AbiDecode {
2192 | fn abi_decode(ref mut buffer: BufferReader) -> Self;
| ^^^^^^^^^^ No method named "abi_decode" found for type "SomeEnum".
2193 | }
|
____
error
--> <autogenerated>:5:61
|
3 |
4 | let args: (SomeEnum,) = decode_second_param::<(SomeEnum,)>();
5 | let result_arr_inside_enum: raw_slice = encode::<SomeEnum>(__contract_entry_arr_inside_enum(args.0));
| ^^^^^^^^^^^^^^^^^^ Trait "AbiEncode" is not implemented for type "SomeEnum".
6 | __contract_ret(result_arr_inside_enum.ptr(), result_arr_inside_enum.len::<u8>());
7 | }
|
____
error
--> <autogenerated>:24:61
|
22 |
23 | let args: (SomeEnum,) = decode_second_param::<(SomeEnum,)>();
24 | let result_str_inside_enum: raw_slice = encode::<SomeEnum>(__contract_entry_str_inside_enum(args.0));
| ^^^^^^^^^^^^^^^^^^ Trait "AbiEncode" is not implemented for type "SomeEnum".
25 | __contract_ret(result_str_inside_enum.ptr(), result_str_inside_enum.len::<u8>());
26 | }
|
____
error: Could not generate the entry method because one of the arguments does not implement AbiEncode/AbiDecode
____
Aborting due to 4 errors.
Error: Failed to compile type_inside_enum
````
## 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.
This PR adds support to express line number mapping from assembly to
source using DWARF object files. Since there are offset details that are
specific to the Fuel ISA, I'm using the existing `SourceMap` that's
already being built, rather than generating directly from the
instructions.
An important point to note is that DWARF uses line-col to express
positions rather than an absolute offset-from-start format. To avoid
computing line-col from absolute positions (which requires re-reading
the source files), I'm changing the source position format everywhere to
line-col. This also simplifies our code at many places (for example, in
`forc-debug`). The only exception is the `addr2line` tool, where the use
of absolute positions is in a function that seemed quite complex to me
to attempt changes. So I have, temporarily, added code to compute
absolute positions from line-col information and then reuse the existing
functions. This is inefficient, but I think that's _okay_ since it's a
standalone tool and the whole thing runs just once for every command
invocation.
The DWARF information is written to a file specified by the `-g` flag
and can be verified using `llvm-dwarfdump --debug-line ./test.obj`. If
the argument to the `-g` flag is a filename that ends with `.json`, then
the existing JSON format is written out, otherwise it's a DWARF object
in an ELF container.
---------
Co-authored-by: Joao Matos <joao@tritao.eu>
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
## Description
This PR implements references to mutable values, `&mut T`, 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 #5063.
References to mutable values:
- can be created using `&mut`
- can be used in type system wherever a type is expected
- coerce to references (`&mut T` -> `&T`) and thus can be used wherever
"regular" references are expected
- can be passed to and returned from functions
The last point is a step in direction of replacing `ref mut` function
parameters with either `&` or `&mut`.
References to mutable values cannot be taken on constants and immutable
variables (see errors below). (Note that we slightly departure from the
Rust counterparts here. Rust allows `&mut` on constants but issues a
warning.)
Additionally, the PR implements `Diagnostic` for the
`ConflictingImplsForTraitAndType` and shows the already existing,
conflicting implementation of the trait.
## Demo
For more demos, see the tests in this PR.
```Sway
let mut x = 123u32;
let r_m_x: &mut u32 = &mut x;
fn fun(p: &mut T) -> &mut T { ... }
impl Foo for &mut &mut T { ... }
type RefMutRefMut = &mut &mut 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).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
This PR implements the new encoding for contracts/scripts/predicates.
https://github.com/FuelLabs/sway/issues/5512 and
https://github.com/FuelLabs/sway/issues/5513
### Contract Calls
When the new encoding is turned on using `--experimental-new-encoding`,
contract calls like the example below will be "desugarized" differently
now.
```sway
let base_asset_id = BASE_ASSET_ID;
let other_contract_id = ContractId::from(0xa38576787f8900d66e6620548b6da8142b8bb4d129b2338609acd121ca126c10);
let test_contract = abi(ContextTesting, other_contract_id.into());
let returned_contract_id = test_contract.get_id { gas: gas, coins: 0, asset_id: BASE_ASSET_ID.value}(1, 2, 3);
```
and will be transformed to
```sway
let base_asset_id = BASE_ASSET_ID;
let other_contract_id = ContractId::from(0xa38576787f8900d66e6620548b6da8142b8bb4d129b2338609acd121ca126c10);
let test_contract = abi(ContextTesting, other_contract_id.into());
let returned_contract_id = contract_call::<ContractId, _>(other_contract_id.into(), "get_id", (1, 2, 3), coins, asset_id, gas);
```
And the important part is the `contract_call` function in the std
library. This function does all the encoding as necessary and delegates
the actual call to an intrinsic function `__contract_call`. Allowing the
protocol to evolve entirely in Sway.
```sway
pub fn contract_call<T, TArgs>(contract_id: b256, method_name: str, args: TArgs, coins: u64, asset_id: b256, gas: u64) -> T
where
TArgs: AbiEncode
{
let first_parameter = encode(method_name);
let second_parameter = encode(args);
let params = encode(
(
contract_id,
asm(a: first_parameter.ptr()) { a: u64 },
asm(a: second_parameter.ptr()) { a: u64 },
)
);
__contract_call::<T>(params.ptr(), coins, asset_id, gas)
}
```
### Contracts
On the other side, when the flag `--expiremental-new-encoding` is turned
on, the contract specification like the one below is being transformed
into all the decoding and encoding necessary.
The mains points are:
- The compiler generates a function called `__entry` that decodes the
method name and its arguments. The method is selected with a bunch of
`if`s at the moment, because we don´t have `match` for string slices.
Then we `decode` the arguments using the correct type, which is a tuple
with all the function arguments, and expand this tuple calling the
function;
- All the contract functions are converted to global functions prefixed
with `__contract_method`;
- Results are encoded and returned using the intrinsic call `__retd`.
Example:
```sway
abi SomeContract {
fn some_function(a: u64) -> u64;
}
impl SomeContract for Contract {
fn some_function(a: u64) -> u64 {
1
}
}
```
will be transformed into
```sway
fn __entry() {
let method_name = decode_first_parameter();
if method_name == "some_function" {
let args = decode_second_parameter::<(u64,)>();
let result = __contract_method_some_function(args.0);
__retd(encode(result));
}
__revert(0);
}
```
### Scripts and Predicates
The protocol to call scripts and predicates will also change and will be
very similar to contracts. See more above. Now when the flag is turned
on, the `main` function will not be entry point anymore. The compiler
will actually generate an `__entry` function that will decode arguments
and encode the result, like contracts.
For example:
```sway
fn main(a: u64) -> u64 {
1
}
```
will be transformed into
```sway
fn __entry() {
let args = decode_script_data::<(u64,)();
let result = main(args.0);
__retd(encode(result));
}
fn main(a: u64) -> u64 {
1
}
```
## Tests
To facilitate testing this PR introduces three changes to our test
harness:
1 - A new parameter can be called to update test output files (abi and
storage json). This facilitates when we only want to copy and paste
these output files to their respective oracles. Brings the framework
closer to a snapshot one.
```
> cargo r -p test --release -- --update-output-files
```
2 - Depending on the configuration at `test.toml` multiple executions of
the same test will be scheduled. At the moment, tests that depend on the
encoding will run with the `--experimental-new-encoding` flag
automatically. For example:
```
Testing should_pass/language/main_args/main_args_copy_copy ... ok
Testing should_pass/language/main_args/main_args_copy_copy (New Encoding) ... ok
```
3 - A new `script_data_new_encoding` was created because we want to
support and run tests with the two encoding for a time. This is also
what flags tests to run with the flag on automatically.
## 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:
- fixes#5559, #5597, and #5492 by removing the `TypeInfo::Unknown` and
providing the required contextual information to type checking of
referencing, dereferencing, `if`, and `match` expressions respectively.
The contextual information provided is taken from the
`ctx.type_annotation()` but always adapted according to the semantics of
the type-checked expression.
- fixes#5583 and #5581 by combining the contextual information coming
from the `ctx.type_annotation()` with the one coming from the enum and
struct instantiation and declaration.
- fixes#5598 by forcing the name-based and not structure-based
identity. In other words, two enums or structs are considered equal only
if they whole `call_path`s are equal. Up to now, we were expecting only
the enum or struct _names_ to be equal, which was treating types with
same names and structures (variants or fields) as equal although they
were defined in different modules.
The PR also introduces parsing of references to mutable values (`&mut
T`). Since this addition does not overlap with the above bug fixes, it
was left as is, and can be fully ignored during the review. Other
changes related to references to mutable values are removed from the
code from type-checking onward to make this PR only fixing the issues.
Continuation on references to mutable values will be done in a separate
PR.
Closes#5559, #5597, #5492, #5583, #5581, #5598.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [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
We now parse the `!` as a TypeInfo::Never, and remove the usage of empty
enums as Never type in our code.
This commit removes completely the DeterministicallyAborts and
TypeCheckUnificationContext.
The DeterministicallyAborts can be removed because the Never TypeInfo is
now propagated using the type checker. Code blocks that return, break,
continue, or call an expression that returns Never, are marked as Never.
Partially fixes#5562.
## 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 does three things:
1. use Rust 1.76.0
2. enable the new `iter_over_hash_type` Clippy lint on relevant crates
3. use `indexmap::IndexMap` to replace any equivalent `HashMap` being
iterated upon with a deterministically ordered alternative
## 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 implements an Iterator trait in std-lib, and adds iter() to Vec.
This also adds parsing and desugaring of for loops.
```
for pattern in iterator {
code_block
}
```
is desugared into:
```
let mut iterable = iterator;
while true {
let value_opt = iterable.next();
if value_opt.is_none() {
break;
}
let value = value_opt.unwrap();
code_block
}
```
This also adds for loops documentation to the control flow docs.
We still have to fix this issues:
- #5567
- #5568
- #5570
- #5571Closes#145
## 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
This PR is a continuation of https://github.com/FuelLabs/sway/pull/5306.
- I am fixing some code reviews issues that were raised in the other PR;
- I am incorporating the encoding version inside the JSON ABI as:
```json
{
"configurables": [],
"encoding": "1", <- look here
"functions": [
{
"attributes": null,
"inputs": [],
"name": "main",
"output": {
"name": "",
"type": 13,
"typeArguments": null
}
}
],
```
This field is a string to allow any kind of versioning we choose.
- This PR has also improved testing and making more explicit how each
type is being encoded.
## Dependencies
- [x] https://github.com/FuelLabs/fuel-abi-types/pull/17
## 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
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
This PR brings
[references](https://github.com/FuelLabs/sway-rfcs/blob/ironcev/amend-references/files/0010-references.sw)
to the language. The overall effort is tracked in #5063.
In the below description, when talking about references we mean `&T`
references - references to immutable values. `&mut T` will be
implemented in upcoming PRs.
The PR implements the following features:
- References exist in the type system and can be declared, aliased,
dereferenced using `*` operator, etc.
- Reference expressions (referencing) are fully supported on all
expressions including the nonsensical one like e.g. `&return;`
- Semantic analysis and checks are implemented for the current
functionality.
- References can be embedded in aggregates.
- References can reference parts of aggreagates.
- References can be passed to and returned from ASM blocks.
- References can be passed to and returned from functions.
- References can be mutable: `let mut r_x = &x`
- Impls can be implemented for non-generic reference types.
- Traits can be implemented for non-generic reference types.
- References work with generics, means `&T` works as expected.
- References can reference references.
- References can be dereferenced using the `*` operator.
- Dereference expressions (dereferencing) are fully supported on all
expressions including the nonsensical one like e.g. `*&return;`
Known limitations:
- When declaring references on references, currently a space (' ') is
mandatory between two ampersands. E.g., `&&a` emits error and must be
written as `& &a`. Extending parser to support, e.g., arbitrary
`&&...&&a` will be done in upcoming PRs.
- Referencing function parameters for copy types works but not with 100%
proper semantics (creates a copy of the parameter).
On the IR level, references are pointers stored as `u64` and do not
exist as a separate concept. They play well with all the existing IR
optimizations.
Since `core::ops::Eq` and `__addr_of()` are still not implemented for
references, checking for equality in tests is done by converting
references to `raw_ptr`s and checking raw pointers. This is essentially
fine and will one day be turned into converting references to typed
pointers which are tests we will anyhow want to have.
Next steps are listed in #5063.
The documentation will be done in a separate PR and provided separately
once feature is considered ready for public usage.
There are several todos in code marked as `TODO-IG`. They will be
resolved in upcoming PRs.
# Demo
For extensive demos of implemented features, see the tests in this PR.
An example of a semantic check:
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [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#4942.
Please do review this carefully. I've added a test triggers the new
error message, but I might very well have forgotten to add something
somewhere.
## 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: Igor Rončević <ironcev@hotmail.com>
## Description
co-developed with: @IGI-111 and @xgreenx
This PR adds support for transaction policies.
What was done:
- bump `fuel-vm` to `0.43.1`
- bump `fuels-rs` to `0.53.0`
- update the `std-lib` to handle new `GTF` codes and the transaction
policies
- update all test
BREAKING CHANGE:
- removed `TxParameters` in favor of `TxPolicies`
- changed `gtf` opcodes
- removed `Mint` from `forc-tx` and cli
## 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: green <xgreenx9999@gmail.com>
Co-authored-by: Elvis <elvisdedic@outlook.com>
Co-authored-by: IGI-111 <igi-111@protonmail.com>
Co-authored-by: xunilrj <xunilrj@hotmail.com>
Co-authored-by: Vaivaswatha Nagaraj <vaivaswatha.nagaraj@fuel.sh>
Co-authored-by: Kaya Gökalp <kaya.gokalp@fuel.sh>
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
## Description
This PR closes https://github.com/FuelLabs/sway/issues/5184, but I have
the impression the same problem can happen with const in other places,
and maybe even with others items.
The problem is that the parsing of `;` is very inconsistent at the
moment. For example, `ItemConst` parses the semicolon, but only as a
`peek`. This because a "parent parser" is actually deciding if the
semicolon is needed or not.
That would be nice if it were more consistent.
## 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#5125 .
There are no tests added as I am not familiar with how these
instructions are actually used. @IGI-111 Please add assignment to
someone who can add the corresponding stdlib functions and tests for it.
---------
Co-authored-by: Cameron Carstens <54727135+bitzoic@users.noreply.github.com>
Co-authored-by: bitzoic <bitzoic.eth@gmail.com>
Co-authored-by: IGI-111 <igi-111@protonmail.com>
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
Will partially address #5049
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [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
Forbid directional formatting characters from
[UAX
#9](https://www.unicode.org/reports/tr9/#Directional_Formatting_Characters)
in literals to fix#5047.
This is similar to rustc's `text_direction_codepoint_in_literal` lint.
Such characters are already implicitly forbidden in other parts of the
syntax.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
Implements associated types parsing.
Adds associated types to trait map.
Modifies resolve_symbol to handle associated types.
Support was added for type ascription, methods parameters, method return
types, and function parameters.
It is still missing fully qualified paths, and checking associated types
name conflicts.
It is also missing updating the documentation.
Closes#4487Closes#610
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [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 introduces `string slices`.
The basic usage is at `test/src/ir_generation/tests/str_slice.sw`:
```sway
let a: str = "ABC";
```
Before this PR `a` would be of type `str[3]`, a string array.
Now both `string slices` and `string arrays` exist. This PR contains a
new intrinsic that converts from string literals to arrays.
```sway
let a: str = "ABC";
let b: str[3] = __to_str_array("ABC");
```
Runtime conversions can be done using
```sway
let a = "abcd";
let b: str[4] = a.try_as_str_array().unwrap();
let c = from_str_array(b);
```
string slices to string arrays can fail, so they return
`Option<str[N]>`; and because of this `try_as_str_array` lives in `std`.
The inverse, `from_str_array` only fails if `alloc` fails and lives in
`core`.
At this PR `string slices` are forbidden at `configurable`, `storage`,
`const`, and main arguments and returns. The reason for these
limitations is the internal structure of `string slices` having a `ptr`.
The optimized IR for initializing the slice is:
```
v0 = const string<3> "abc"
v1 = ptr_to_int v0 to u64, !2
v2 = get_local ptr { u64, u64 }, __anon_0, !2
v3 = const u64 0
v4 = get_elem_ptr v2, ptr u64, v3
store v1 to v4, !2
v5 = const u64 1
v6 = get_elem_ptr v2, ptr u64, v5
v7 = const u64 3
store v7 to v6, !2
v8 = get_local ptr slice, __anon_1, !2
mem_copy_bytes v8, v2, 16
```
## 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 complements https://github.com/FuelLabs/sway/issues/4912 with
better name and doc comments for parser recovery.
## 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
Closes https://github.com/FuelLabs/sway/issues/4729.
The trick part of this PR is that `TraitItems` were being parsed as
`(TraitItem, SemicolonToken)`. The problem is that to recover from an
error we call the `error` method of the `Parser` trait. And it is very
hard to come up with a generic implementation for the tuple. Which type
of tuple do we call its `error` method, and how do we return a valid
tuple in all cases? Impossible.
So that is why I moved the `SemicolonToken` to inside the `TraitItem`.
Another benefit is that we can recover from missing semicolons with nice
error messages.
## 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
Closes https://github.com/FuelLabs/sway/issues/4910.
Closes https://github.com/FuelLabs/sway/issues/4909.
Closes https://github.com/FuelLabs/sway/issues/4908
The trait `Parse` now contains a do-nothing `error` function that
returns the error variant for that item, if it has one. This allows
generic parsing functions like `Vec`, `Annotated` etc... to be able to
recover and continue if desired.
Now the parser continues even if strange things at the item level.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
This PR closes https://github.com/FuelLabs/sway/issues/4968. The problem
here is that doc comments are special in the sense that they demand an
item after.
I am following the `rustc` error message of my machine, but rust
playground message is a little different. Not sure which way we want to
go.
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=34097e067111a355e70767be7965952c
## 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 closes https://github.com/FuelLabs/sway/issues/4911.
It primarily does two things:
1 - Extend a lot of functions that return `CompileError` to return
`Vec<CompileError>` allowing multiple errors to return;
2 - Implements the concept of parser recovery.
This happens when using the function `guarded_parse_with_recovery`,
exemplified below. When the guard fails, this function return
`Ok(None)`; when it succeeds it returns `Ok(item)`. The exciting part is
when the parsing fails.
It returns an instance of `Recoverer` which contains a reference to the
original parser before any tentative parser was done and the forked as
left by the parsing function.
The idea is that it is the caller's responsibility to put the forked
parser in a "good position". For that, it offers some helpers function
and access to the forked parser.
To avoid boilerplate code one recovery strategy is already implemented
`recover_at_next_line_with_fallback_error` which consumes everything at
the forked parser's current line and emits an error if none were
generated by the tentative parser.
```rust
match parser.guarded_parse_with_recovery::<LetToken, StatementLet>() {
Ok(None) => {}
Ok(Some(item)) => return stmt(Statement::Let(item)),
Err(r) => {
let (spans, error) =
r.recover_at_next_line_with_fallback_error(ParseErrorKind::InvalidStatement);
return stmt(Statement::Error(spans, error));
}
}
```
With this, we have the LSP not "dying" when a strange error happens. The
errors themselves are not brilliant, but they will be improved in other
PRs.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
This pull request is an upgrade to a `fuel-core 0.20.1` release.
The biggest changes coming from this new release is a rework of how
AssetId is structured to support [granular asset
minting](https://github.com/FuelLabs/fuel-specs/pull/491). This means a
contract can mint and burn multiple AssetId's, and the ContractId !=
AssetId.
---------
Co-authored-by: bitzoic <bitzoic.eth@gmail.com>
Co-authored-by: Cameron Carstens <54727135+bitzoic@users.noreply.github.com>
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
Co-authored-by: Brandon Kite <brandonkite92@gmail.com>
Co-authored-by: Sophie <sophiedankel@gmail.com>
## Description
Closes https://github.com/FuelLabs/sway/issues/4935
- In order to write comments for the else block when it only contains a
comment, I had to add the span to `CodeBlockContents`
## 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).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [ ] I have requested a review from the relevant team or maintainers.
## Description
This changes addresses the issues introduced in #4878
The `error_emitted` pattern is replaced by a scoping method on `Handler`
that collects errors within a closure and will error out if new erros
are introduced.
All instances of introducing `ErrorEmitted` as a literal value have now
been replaced by passing arround the receipt of the error emission
through the error representing values. Some types from the AST had to be
moved to `sway-types` to avoid circular dependencies introduced by this
change.
This also repairs some of the discrepancies to emitted warnings
introduced in #4878, as well as rename some of the `Handler` methods.
Fixes#4885Fixes#4886
## 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 is part of https://github.com/FuelLabs/sway/pull/4794. It
implements the bare minimum to support `u256` constants across the
stack.
They are represented in sway in hex literals with `u256` suffixes. Hex
without suffix will still be `b256`, for backward compatibility until we
implement `u256` completely. Then we can decide what to do.
There are multiple places in the code that will fail if the literal does
not fit in u64. This will be fixed later in a specific PR for big u256.
Some places have temporary `unwrap()`, that will be removed later. I can
try to remove them now, if necessary.
I am leaving all documentation updates for when everything is
implemented.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
---------
Co-authored-by: Anton Trunov <anton.a.trunov@gmail.com>
