## Description
Closes#3938
### Problem
I've submitted a few PRs (#4129, #4093, #4005) implementing a new way of
formatting comments in tackling #3938, but after submitting #4129 and
following that working on formatting storage comments in a local branch
realized that the method of formatting previously by writing
`write_comments(..)` between every span is getting very unwieldy. That
method results in a lot of repeated calls to `write_comments()`, and in
some cases where we have to check if some value exists, it would lead to
even more vertical space taken up because we have to do something like
this:
```rust
...
if let Some(item) = my_item {
write_comments(
formatted_code,
start..end,
formatter,
)
// do other things
}
...
```
My sense is that this will probably lead to the formatter code being
hard to maintain in future because of the length of each `Format`
implementations, and having to work your way through a lot of
conditional code and repeated calls to `write_comments(..)` isn't a very
nice experience. In #4005, the comment formatting for `ItemAbi` alone
led to **56 additional line insertions** in that PR (previously it was
54 LoC, which means the LoC doubled!)
### Solution
We adapt the original approach of inserting comments, but this time on a
local scale. That means we parse each node on its own, compare its
unformatted and formatted versions, and find out where to insert
comments found between spans. Unlike the original approach, this
approach will parse and format while the AST node is being visited and
formatted - that means the entire `handle_comments(..)` that reparses
the entire `Module` can be deprecated once this PR is in.
This is done mainly through the function `rewrite_with_comments(..)`
that is called at the end of a `impl Format`. Essentially what this
function does is it parses the unformatted and formatted versions of the
currently visited node with `parse_snippet::<P: sway_parse::Parse +
Format>(..)`, finding the comments between the unformatted spans, and
inserting them into the formatted spans.
Based on the `CommentKind` of the found comments, we do some formatting
to decide how they should be written.
Of course, this also means that unlike the previously proposed method of
using `write_comments()` everywhere, where we have the indentation
context, this new approach means that we yet again do not have the local
context. To figure out indentation, we assume that each comment will
always be 'pinned' to some node below it - if this node does not exist
we try to 'pin' to a node above it instead.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
Closes#4206
Three main changes:
* Add new configuration-time constants tests to `sdk-harness`. This is
important to make sure there are no regression in the backend.
* Add a new example for `configurable`
* Document `configurable`
* Had to bump to `fuels 0.37` to be able to update `configurable`
variables from the SDK.
## 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
Implement RFC 0006, fix#4191.
Remove the `dep` reseved keyword in favor of `mod`.
Change path resolution for submodules to use an adjascent file at the
root and a folder named after the current module in other cases.
Remove the need for an argument to `library`, the LSP now points to
empty spans at the top of module files.
The library names are now determined by the file name, or the package
name at the top level.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
Closes#4223
Basically just showing that associated methods do actually work.
## 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] 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
Followup to #4005
makes `abi_supertraits` test pass comment formatting without
`handle_comments`.
In fixing this, this also inadvertently led to me fixing other
formatting issues:
- There may be comments before the module declaration - the first one
was tagged as a `Trailing` comment, even though it should not be. Added
a 0 check within lexing for this.
- Massively simplified `comments.rs` - before, we used to arbitrarily
compare to the previous token, but now that we have the concept of
`Trailing` and `Newlined` comments, we do not need to do this. We also
used to write an indent after writing a trailing comment, but I think
this should be moved up-one-level to whereever the trailing comment was
written. There is also an update to a test that retains the trailing
nature of a trailing comment in an existing test.
For the rest of changes, they seem largely unrelated to what this PR
claims to solve, so I'll go change by change:
- within `item_fn/mod.rs`: This fixes the supertraits test example
(which had a weird spacing for expected comment output)
- within `module/mod.rs`: We format comments between items (this fixes
the the tests like `abi_comments` and `abi_supertrait` that have
comments written between items.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
Added the Result type to the same page where Identity, ContractId, and
Address are covered. Definition was taken from standard library repo -
https://github.com/FuelLabs/sway/blob/master/sway-lib-std/src/result.sw
---------
Co-authored-by: Camila Ramos <camiinthisthang@Camilas-MacBook-Pro-3.local>
Co-authored-by: Mohammad Fawaz <mohammadfawaz89@gmail.com>
## Description
Updated match examples to be more intuitive and helpful for the reader,
replacing function and variable names like foo, bar, etc.
## 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).
- [ ] 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: Camila Ramos <camiinthisthang@Camilas-MacBook-Pro-3.local>
Co-authored-by: Kaya Gökalp <kaya.gokalp@fuel.sh>
Co-authored-by: Mohammad Fawaz <mohammadfawaz89@gmail.com>
## Description
This moves the examples workspace manifest introduced in #4118 into the
`examples/` directory and cleans it up a bit.
We also now integrate the examples workspace into CI, making the old
`examples-checker` script redundant. This old script is also removed as
a part of this PR.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] 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
Updated msg_sender example for beta-3
---------
Co-authored-by: Mohammad Fawaz <mohammadfawaz89@gmail.com>
Co-authored-by: Braqzen <103777923+Braqzen@users.noreply.github.com>
## Description
Part of #3938
This PR handles **comment formatting** for the abi,
as well as comments before modules (this is to pass the test suite)
This was a pretty tricky PR to tackle, since I cycled through several
thought processes while trying to finish this.
1) I tried to solve the problem at the parse/lex level - cycled back to
the thought of re-parsing the file to create a special commented AST -
worked a bit on that before I scrapped the whole idea because it just
didn't seem necessary.
2) I then started trying to solve it in the originally discussed way,
attempting to format the comments within each `Format` implementation.
This started off well - it was trivial to navigate within a span, but it
was particularly tricky navigating _between_ spans, and for formatting
the ABI, it turns out that trailing comments can appear after an
attribute, or even after the fn signature. I initially tried to
implement a way to 'look forward', but soon realized it was impossible
unless we want to hold a reference to the unformatted code in each
`Format` implementation (which I guess is what I ended up doing anyway)
3) So, I ended up looking for a way to 'look back', but still used 'look
ahead' for comments:
Comments will always be 'anchored' to the next span - meaning to say,
when a trailing comment exists, it will 'belong' to the next span
instead of the span(s) on the same line. This means that when we know
the locations of 2 spans, we can easily call `write_comments` to insert
the comments in between.
While we mentioned that looking forward is impossible, one place we
_can_ look forward though, is between comments in the unformatted code,
if there are multiple comments to be written at once. This is basically
what `collect_newlines_after_comment_span()` is doing.
### Other notable changes
- Renamed `write_comments_from_comment_map` to `write_comments` to be
more concise.
- Introduce `CommentsContext` to hold both `CommentMap` and
`unformatted_code`, instead of exposing `unformatted_code` at the
Formatter level.
- Changed generic `T` to `ItemKind` within attribute.rs. This is so we
can have access to `span()`.
- Lexing the commented token tree now gives us `CommentKind` info.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
---------
Co-authored-by: Kaya Gökalp <kaya.gokalp@fuel.sh>
## Description
Please see the issue #3798.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Tasks
- [x] check the supertrait(s) for the ABI is implemented
- [x] fail with an error when a supertrait for ABI is not implemented
- [x] check that ABI implementation methods can use its supertrait's
methods (the one that are defined at the ABI _declaration_ site)
- [x] check that the supertrait's methods can be used in the actual
contract methods
- [x] check that methods in supertraits are not be available externally
(i.e. they're not actually contract methods)
- [x] implement that Ownable example
- [x] formatter tests
- [x] add new section in the Sway docs illustrating this language
feature
---------
Co-authored-by: Mohammad Fawaz <mohammadfawaz89@gmail.com>
API change:
Previous:
```rust
pub fn get<T>(key: b256) -> T;
pub fn get(self, key: K) -> V;
```
Now:
```rust
pub fn get<T>(key: b256) -> Option<T>;
pub fn get(self, key: K) -> Option<V>;
```
`Option::None` indicates that the storage slot requested in not
available.
- Updated all storage intrinsics to return a `bool` except for
`__state_load_word` because it already returns the value loaded. The
`bool` returned represents the previous state of the storage slots as
described in the specs. I was not able to update `__state_load_word` to
return both the value loaded and the `bool` unfortunately because I hit
various hiccups along the way, particularly in IR/codegen.
- Updated `get` and `StorageMap::get` in the standard library to return
an `Option` based on the Boolean mentioned above. In the copy type case,
I had to use `asm` blocks instead of `__state_load_word` until we're
able to return a struct from an intrinsic.
- I did not update `store` and `StorageMap::insert` to return an
`Option`, for now, because that would involve an extra storage read to
return the previous value, if available. We can think about whether this
is worth it at some point.
- I added `unwrap` and `unwrap_or` where it makes sense in `StoargeVec`.
- Update various docs, examples, and tests.
Closes https://github.com/FuelLabs/sway/issues/3318
I will open separate issues for updating `__state_load_word` and
thinking about making `store` and `insert` also return an `Option`.
With these changes it is no longer possible to do `Option::None()`
instead it should be done with `Option::None`.
This changes also fixes enum turbofish without parenthesis so
`Option::None::<T>` can be used.
Ref #3585 (Does not close but addresses other issue mentioned on the
comments)
Closes#3375
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
The lack of this annotation implies the method is non-payable. When
calling an ABI method that is non-payable, the compiler must emit an
error if the amount of coins to forward is not guaranteed to be zero.
The compiler also emits an error if the method signature and the method
implementation have different `#[payable]` annotations.
## Assumptions
Currently, the analysis of non-zero coins is very simple and only checks
if the special `coins:` contract call parameter is the zero `u64`
literal directly or can be reached through a chain of variable/constant
definitions.
## Tests
- [x] Must fail when scripts call non-payable methods with non-zero
coins as a literal
- [x] Must fail when scripts call non-payable methods with non-zero
coins as a constant
- [x] Must fail when scripts call non-payable methods with non-zero
coins as a variable definition
- [x] Must fail when contracts call non-payable methods with non-zero
coins
- [x] Must fail when there is an extra `#[payable]` annotation in method
implementation (not mentioned in its signature)
- [x] Must fail when the `#[payable]` annotation in method
implementation is missing (but mentioned in its signature)
close#1608
## TODOs
- [x] Fix `#[payable]` annotations for the standard library
- [x] Fix the empty parens issue for formatting attributes: #3451
- [x] Parser should allow us write annotations like so: `#[storage(read,
write), payable]`: #3452
- [x] Refactor `#[payable]` annotations in this PR in the style above
- [x] Add more complex formatter unit tests with `payable`
- [x] As pointed out by @mohammadfawaz, the SDK can bypass payable
annotations and one option would be to add function attributes to the
[JSON ABI
schema](https://fuellabs.github.io/fuel-specs/master/protocol/abi/json_abi_format.html)
and process it in the SDK (see these issues:
https://github.com/FuelLabs/fuel-specs/issues/446 and
https://github.com/FuelLabs/fuels-rs/issues/742)
- [x] Bump `fuels-rs`'s version
Co-authored-by: Mohammad Fawaz <mohammadfawaz89@gmail.com>
The current `core::num` name is not well aligned with types like `b256`
which are not numeric types.
In addition, in Rust, methods like `min(), `max()` and `bits()` are in
the `primitives` module.
Closes#2777
This adds support for reassigning array elements.
We now support this by extending reassignment `ProjectionKind` with a
new `ArrayIndex` variant which keeps track of the typed array index
reassignnment during semantic analysis.
Afterwards we implement this new projection in IR generation by lowering
to the `insert_element` IR instruction which updates the array element
value.
Closes https://github.com/FuelLabs/sway/issues/2457.
Co-authored-by: Mohammad Fawaz <mohammadfawaz89@gmail.com>
While a final design for the organization of `std` will likely involve
more discussion (& consideration of the proposed `Contract` type with
some of the existing free functions converted to methods on the
`Contract` type), the changes I've made here remove some weirdness.
This is a breaking change, so it might be a good time to clean at least
this up.
I've left the `vm` directory as currently, it seems like the only good
use of a subdirectory in `std`.
If anyone thinks this needs more discussion we can mark this a draft.
ref #1759
Closes#1078
* New trait `From<T>` in a new library called `convert.rs`
* Most changes are trivial
* Added `From` to the prelude
* Had to modify `from()` in `U128`, `U256`, and `B512` to take a tuple
of components instead of multiple arguments to conform to the trait.
This is a breaking change of course.
* Updating lock files for all the examples.
Fixes https://github.com/FuelLabs/sway/issues/1436.
This PR first removes the need for `~` in `~Foo::bar` by first delaying
the interpretation of `Foo::Bar` (associated call, free function call,
or enum variant construction?) until type checking. This is achieved
with `ExprKind::AmbiguousPathExpression`. During type checking, we ask
whether `Foo` (and any prefixes) is a module, or an enum. If it's
neither, we attempt type checking as an associated function call.
Otherwise, we continue as if we had a `ExpressionKind::DelineatedPath`.
Once `~` is made redundant, it's then also removed from the language and
so also from tests, examples, and the standard library.
Co-authored-by: Alex Hansen <alex@alex-hansen.com>
Opening up for visibility, still reading through `cargo doc` and
previous comments related to this
Closes#161
- [x] #3027
- [x] #3033
- [x] #3036
- [x] #3038
- [x] #3088
- [x] #3090
Co-authored-by: Alex Hansen <alex@quickr.us>
Co-authored-by: Alex <alex@system76-pc.localdomain>
Closes#2912
Even though `transfer_to_output` is technically more correct, users
really understand this as transferring to an address. Besides, the name
`transfer_to_address` aligns better with the names of its parameters:
```rust
(amount: u64, asset_id: ContractId, to: Address)
```
And also with other functions in `token.rs` (such as `mint_to_address`).
I also did some minor refactoring of the function.
Added missing END to ANCHOR to limit call examples shown in the docs to the ones presented previously
Co-authored-by: John Adler <adlerjohn@users.noreply.github.com>
Co-authored-by: Alex Hansen <alex@alex-hansen.com>
* Remove send address check
Given that send() can be called by any address, we shouldn't check whether it's being called by the contract creator.
* Added requested changes
Co-authored-by: Mohammad Fawaz <mohammadfawaz89@gmail.com>
Co-authored-by: Alex Hansen <alex@alex-hansen.com>
* vec and storag vec
* Update docs/src/common-collections/storage_vec.md
Co-authored-by: Braqzen <103777923+Braqzen@users.noreply.github.com>
* Update docs/src/common-collections/storage_map.md
Co-authored-by: Braqzen <103777923+Braqzen@users.noreply.github.com>
* Addressing more comments
* Some extra spacing to separate the notes, even though the linter complains
Co-authored-by: Braqzen <103777923+Braqzen@users.noreply.github.com>
Co-authored-by: Alex Hansen <alex@alex-hansen.com>
* Add warning about BASE_ASSET_ID and write example ownership contract
* Typos
* Run forc fmt
* Update docs/src/blockchain-development/access_control.md
Co-authored-by: John Adler <adlerjohn@users.noreply.github.com>
* Update docs/src/blockchain-development/access_control.md
Co-authored-by: John Adler <adlerjohn@users.noreply.github.com>
* Update to account for BASE_ASSET_ID now to be a ContractID and refer to the zero address in general
* Typo
* Commit suggestions
* Update docs/src/blockchain-development/access_control.md
Co-authored-by: John Adler <adlerjohn@users.noreply.github.com>
Co-authored-by: John Adler <adlerjohn@users.noreply.github.com>
Co-authored-by: Mohammad Fawaz <mohammadfawaz89@gmail.com>
Add support for raw identifiers and improve reserved keywords checking.
This commit deals with the usage and checking of reserved keywords
as identifiers, for code like:
```
fn main() {
let mut mut = 0;
}
It introduces a new error that checks if an identifier is a reserved
keyword:
```
error
--> /main.sw:4:13
|
2 |
3 | fn main() {
4 | let mut mut = 0;
| ^^^ Identifiers cannot be a reserved keyword.
5 | }
|
____
```
There was an existing issue in the standard library, which
has a library/module named `storage`.
Instead of working around this by renaming it to something else,
an alternative solution with raw identifiers is implemented.
This raw identifier feature is implemented at the lexer level,
and allows you to use keywords as identifiers in places that
generally wouldn't be allowed.
Rust and a bunch of other modern languages also provide this escape
hatch, and it seemed the simplest solution for me to handle the issue.
It activates by declaring an identifier prefixed with `r#`, just like
Rust.
The complexity on the codebase to support this feature is pretty
minimal, but if there any objections to this, I can easily remove it,
but some other solution to the issue above will need to be figured out.
Closes https://github.com/FuelLabs/sway/issues/1996.
Co-authored-by: Mohammad Fawaz <mohammadfawaz89@gmail.com>
