## Description
This PR is a prequel to https://github.com/FuelLabs/sway/pull/7015,
trying to optimize the compiler to alleviate the hit of having more
items, `impl` etc...
We have here two optimizations:
1 - We spend a lot of time counting newlines when converting byte
offsets to `LineCol`. Now, we calculate line offsets just once, and use
binary search later to find which line a byte offset is at.
2 - `QueryEngine::get_programs_cache_entry` was cloning the whole
`TyProgram`. That is why `did_change_with_caching` was always getting
worse, as the program was increasing in size. Now all compilation stages
are behind `Arc`, which makes the `clone` free.
## Analysis
Putting a `dbg!(...)` like the image below, and calling `counts`
(https://github.com/nnethercote/counts).
```
cargo bench -- traverse 2>&1 | grep "sway-types/src/span.rs:29:9" | counts
```
I get the following results:
```
972102 counts
( 1) 156720 (16.1%, 16.1%): [sway-types/src/span.rs:29:9] self.pos = 0
( 2) 15900 ( 1.6%, 17.8%): [sway-types/src/span.rs:29:9] self.pos = 104
( 3) 15840 ( 1.6%, 19.4%): [sway-types/src/span.rs:29:9] self.pos = 107
( 4) 2280 ( 0.2%, 19.6%): [sway-types/src/span.rs:29:9] self.pos = 19281
( 5) 2280 ( 0.2%, 19.9%): [sway-types/src/span.rs:29:9] self.pos = 19285
( 6) 2280 ( 0.2%, 20.1%): [sway-types/src/span.rs:29:9] self.pos = 19287
( 7) 2280 ( 0.2%, 20.3%): [sway-types/src/span.rs:29:9] self.pos = 19292
( 8) 2280 ( 0.2%, 20.6%): [sway-types/src/span.rs:29:9] self.pos = 19323
( 9) 2280 ( 0.2%, 20.8%): [sway-types/src/span.rs:29:9] self.pos = 19327
( 10) 2280 ( 0.2%, 21.0%): [sway-types/src/span.rs:29:9] self.pos = 19329
( 11) 2280 ( 0.2%, 21.3%): [sway-types/src/span.rs:29:9] self.pos = 19334
( 12) 870 ( 0.1%, 21.4%): [sway-types/src/span.rs:29:9] self.pos = 4285
...
```
This means that `line_col` is being called 972k times. 16% is for
position zero, which should be trivial. The rest will iterate the whole
file source code to count number of lines. Making the real complexity of
the work here something like `O(qty * self.pos)`. And some values of
`self.pos` are not trivial at all.
## Checklist
- [ ] I have linked to any relevant issues.
- [ ] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [ ] I have requested a review from the relevant team or maintainers.
## Description
This PR is part of https://github.com/FuelLabs/sway/issues/6860.
It continues the implementation of more `std` library "traits" for
arrays.
It also fixes a small error when formatting "const generics
declarations".
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
Fix#6804
## Checklist
- [x] I have linked to any relevant issues.
- [ ] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [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.
Co-authored-by: IGI-111 <igi-111@protonmail.com>
## Description
This PR refactors `swayfmt` to be able generate code from arbitrary
lexed trees. Arbitrary means a lexed tree that can be fully or partially
created in-memory by manipulating the tree structure in code. It does
not need to necessarily be backed by source code. This is needed to be
able to reuse `swayfmt` for generating source code from tools that
analyze and modify Sway code, as explained in #6779.
This PR makes the `swayfmt` independent of spans backed by the source
code, by doing the following changes:
- Keywords are rendered by using theirs `AS_STR` associated constants.
- The `Token` trait is extended with the `AS_STR` associated constant,
and tokens are rendered by using that constant.
- `Ident`s are rendered by using theirs `as_str()` methods. This method
takes the textual implementation from `Ident::name_override_opt` if it
is provided, and ignores the span in that case.
- `Literal`s are rendered based on the literal value and not their
spans. The exception are numeric literals that do not have empty spans.
Those are considered to be backed by source code and are rendered as
written in code, e.g., `1_000_000u64`.
The PR also fixes some existing bugs in `swayfmt`:
- `use path::{single_import,};` will be formatted as `use
path::single_import;`
- `use path::{a,b,};` will be formatted as `use path::{a, b};`
- partial addresses #6802 by rendering annotations for final values.
- partial addresses #6805 by properly rendering final values, but still
not using the expected field alignment.
The PR also removes the `path` parameter from the `parse_file`. It was
used only to provide an unnecessary dummy `source_id` which was always
pointing to the package root file.
Closes#6779.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
closes#6447
## 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
We recently started using indoc to improve readability in fuelup. This
PR just adds uses the `indoc!` macro to all the existing tests.
---------
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
This is a small fix to match the indentation for opening brace after a
where clause is seen. This should fix#5468
cc: @Braqzen
The change is near trivial.
## 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.
Co-authored-by: Kaya Gökalp <kaya.gokalp@fuel.sh>
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
## 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
Run `forc fmt` on the std-lib
## 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
Changes needed to build #5404 and #5405
## Improvements
1. Use byte-offset instead of chars offset
2. Enhanced `asm` formatting
## Better output when tests fail
## 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: Cesar Rodas <cesar@Cesars-MacBook-Pro-2.local>
## 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 was discovered while adding tests for #2790, #2497. This is a
regression from #4185
## 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
Improve breaking method calls into multiple lines following Rust rules.
A two parts method call is never broken into multiple lines, longer
chains are broken if they are long enough (counting their arguments).
## 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.
Closes#3472
What this does:
- Removes use of `Config` options that were partially implemented
- Fixes the default implementations for `Config`. This removes the match
arms in the implementations of the `CurlyBrace` trait and just handles
the default, eg `ItemBraceStyle::SameLineWhere`
- Adds tests for items with `where` clauses, ie `ItemImpl`,
`ItemStruct`, `ItemTrait`, which weren't being tested thoroughly enough
- Updates to code quality in the `Config`, and documentation for the
default config's options
Fixes#3474
## Description
Breaks long expressions (focusing into chained methods calls but will
cover all expressions) into multiple lines
## 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.
Fixes#5060
## Description
Empty implementations have a bug with new lines
## 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 is part of #5052
## Description
There was a bug in the formatter whenever a comment as followed by a
doc-comment, this was due the `insert_after_span` was not allowed to
return a negative offset (due types constraints). But sometimes this
function should let their callee know to remove some bytes.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] 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
Fix a bug where the `pub` token in any `pub mod` expression would get
elided by swayfmt.
## 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.
Closes#4185
## Description
The solution we adopted as a start would have us take the space between
leaf spans, except a problem was that a doc comment would be a leaf span
but a regular comment would not be a leaf span. Usually this would not
be an issue, but in certain cases where we perhaps want to comment code
out temporarily to test changes, the formatter would move comments
around unintentionally.
For example, a doc comment followed by a commented out function (as
shown in the issue) would cause the commented out function to move away
from the doc comment:
```rust
contract;
abi MyContract {
fn test_function() -> bool;
}
impl MyContract for Contract {
/// This is documentation for a commented out function <-- a newline is inserted after this comment
// fn commented_out_function() {
//}
fn test_function() -> bool {
true
}
}
```
Situations like these could ruin developer experience.
The main problem is that the entire whitespace gap between 2 leaf spans
could have multiple comments with multiple newline sequences, and all
these would be squished to the end of the first leaf span when inserting
the newlines.
The fix is to take 'snippets' while we're scanning for newline sequences
to insert and try to detect comments within these snippets. We then
split insertion of newline sequences into two phases: one before the
first comment (which is described above, which caused the issue above),
one after the last comment.
## 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).
- [ ] 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#4473
This contains quite a big change for how we insert newlines into the
formatted code - currently we would get a `Vec<NewlineSequence>` to
insert into a span, and this PR changes this to just a
`NewlineSequence`.
The bug was a result of collecting this `Vec` stated above when
**checking between the last unformatted leaf span and the end of code
leaf span that was manually inserted**. We then end up inserting it all
in one place - resulting in a bunch of newlines rather than just 1.
The reason for changing this to just a single `NewlineSequence` is
because IMO there isn't really a situation where we might have multiple
newline sequences between 2 leaf spans such that we want to insert a
`Vec<NewlineSequence>`, but it's causing problems when it comes to the
situation described above.
To get a look at how this situation looks like - the test case added
shows an example of this.
## 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).
- [x] I have requested a review from the relevant team or maintainers.
Co-authored-by: Kaya Gökalp <kaya.gokalp@fuel.sh>
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
Closes#3938
### Problem
I've submitted a few PRs (#4129, #4093, #4005) implementing a new way of
formatting comments in tackling #3938, but after submitting #4129 and
following that working on formatting storage comments in a local branch
realized that the method of formatting previously by writing
`write_comments(..)` between every span is getting very unwieldy. That
method results in a lot of repeated calls to `write_comments()`, and in
some cases where we have to check if some value exists, it would lead to
even more vertical space taken up because we have to do something like
this:
```rust
...
if let Some(item) = my_item {
write_comments(
formatted_code,
start..end,
formatter,
)
// do other things
}
...
```
My sense is that this will probably lead to the formatter code being
hard to maintain in future because of the length of each `Format`
implementations, and having to work your way through a lot of
conditional code and repeated calls to `write_comments(..)` isn't a very
nice experience. In #4005, the comment formatting for `ItemAbi` alone
led to **56 additional line insertions** in that PR (previously it was
54 LoC, which means the LoC doubled!)
### Solution
We adapt the original approach of inserting comments, but this time on a
local scale. That means we parse each node on its own, compare its
unformatted and formatted versions, and find out where to insert
comments found between spans. Unlike the original approach, this
approach will parse and format while the AST node is being visited and
formatted - that means the entire `handle_comments(..)` that reparses
the entire `Module` can be deprecated once this PR is in.
This is done mainly through the function `rewrite_with_comments(..)`
that is called at the end of a `impl Format`. Essentially what this
function does is it parses the unformatted and formatted versions of the
currently visited node with `parse_snippet::<P: sway_parse::Parse +
Format>(..)`, finding the comments between the unformatted spans, and
inserting them into the formatted spans.
Based on the `CommentKind` of the found comments, we do some formatting
to decide how they should be written.
Of course, this also means that unlike the previously proposed method of
using `write_comments()` everywhere, where we have the indentation
context, this new approach means that we yet again do not have the local
context. To figure out indentation, we assume that each comment will
always be 'pinned' to some node below it - if this node does not exist
we try to 'pin' to a node above it instead.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
Implement RFC 0006, fix#4191.
Remove the `dep` reseved keyword in favor of `mod`.
Change path resolution for submodules to use an adjascent file at the
root and a folder named after the current module in other cases.
Remove the need for an argument to `library`, the LSP now points to
empty spans at the top of module files.
The library names are now determined by the file name, or the package
name at the top level.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
Followup to #4005
makes `abi_supertraits` test pass comment formatting without
`handle_comments`.
In fixing this, this also inadvertently led to me fixing other
formatting issues:
- There may be comments before the module declaration - the first one
was tagged as a `Trailing` comment, even though it should not be. Added
a 0 check within lexing for this.
- Massively simplified `comments.rs` - before, we used to arbitrarily
compare to the previous token, but now that we have the concept of
`Trailing` and `Newlined` comments, we do not need to do this. We also
used to write an indent after writing a trailing comment, but I think
this should be moved up-one-level to whereever the trailing comment was
written. There is also an update to a test that retains the trailing
nature of a trailing comment in an existing test.
For the rest of changes, they seem largely unrelated to what this PR
claims to solve, so I'll go change by change:
- within `item_fn/mod.rs`: This fixes the supertraits test example
(which had a weird spacing for expected comment output)
- within `module/mod.rs`: We format comments between items (this fixes
the the tests like `abi_comments` and `abi_supertrait` that have
comments written between items.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
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
closes#4098
This PR moves all test related macros into a new crate `test_macros`
(this includes `assert_eq_pretty!` from a previous PR (#3960). The
motivation for this is when working with unit tests for maybe an
expression, I realized that `fmt_test` is being re-implemented
everywhere.
We create 2 new macros `fmt_test_expr` and `fmt_test_item`, which are
now used in the tests, instead of creating a new local `fmt_test!` for
each AST type.
This cuts down quite a bit of LoC and boilerplate code, since for each
AST kind we were re-implementing `fmt_test!` in each `test.rs` file.
## 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).
- [ ] 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 Dankel <47993817+sdankel@users.noreply.github.com>
## Description
Ran on test branch & working as intended. Only beginning of file `//!`
is collected as `DocComment` with `DocStyle::Inner` which is only
collected at the `Module` parsing stage. This ensures that any `//!`
found after the module docs will be treated as normal comments for now.
Ref #4112 for tracking further progress in allowing inner doc comments
for `Item`.
## Checklist
- [x] I have linked to any relevant issues. Closes#4097
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
closes#4092
Note that this PR also moves the block indentation logic up one level
into the `ItemFn` level instead of at the `CurlyBrace` impl.
## 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.
---------
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## 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>
closes#3597
It's not entirely accurate that this addresses the issue, since the
usage of a macro here (credits to
[ripgrep](fe97c0a152/tests/macros.rs (L18)))
is only to improve diff printing, and all the setups are abstracted into
functions, which are reused throughout the tests. I'm not sure that we
need macros here for those purposes, so I did not use them, but the
functions themselves accomplish the goal of reducing boilerplate anyway,
so I am marking it as closing that issue ;)
I've also renamed the fn names. Some of their names are inconsistent -
some start with 'test_...', some start with the subject being tested
e.g. 'fn struct_...' or 'fn comments_...' since the tests are already
labelled with `#[test]` I removed the 'test_' prefix from all functions.
