## Description
Fixes the same issue found here:
https://github.com/FuelLabs/sway/pull/4038#discussion_r1105153934, but
missed out in other locations. This has caused new PRs to not fail on
`forc-fmt --check` even if they contained formatting violations, see:
https://github.com/FuelLabs/sway/pull/4129
## Checklist
- [ ] I have linked to any relevant issues.
- [ ] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
This allows for specifying a `--salt` for the top-level contract member
when running `forc deploy`. Right now, we only enable this for
*packages*, and not for workspaces with more than one package due to
some ambiguities that arise (see comment note in code). I'll open an
issue to track relaxing this constraint a little. Edit: opened
https://github.com/FuelLabs/sway/issues/4117.
I noticed we also had no way of specifying maturity, so have added a
`--maturity` flag for this as well.
These flags are shared with the `forc-tx` crate in order to try and
provide some consistency (in help output and flag representation) across
our CLI tooling.
Ideally we'd like to ship this feature in the Sway release that ends up
in the fuelup beta-3 toolchain - otherwise users following the
quick-start guide will be unable to re-deploy the same contract to the
network as it will already exist - they'll need to be able to provide a
salt.
## 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.
## Description
This introduces a `Command::parse` constructor that emulates the
behaviour of the `clap` parse constructor in order to provide a more
consistent clap-like CLI experience. For context, we cannot use the
generated `parse` command due to limitations in clap's ability to handle
trailing subcommands as mentioned in #3804.
We switch to using `thiserror` in the library in order to allow for
handling error cases (necessary for the new `parse` constructor) and to
provide cleaner, more detailed error cause traces.
The help and version output no longer panic, and now behave like regular
clap applications. Closes#3886.
Also adds an example command invocation to the end of the `--help`
output.
## 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.
## Description
closes#4027
This is a fix for the formatter being called to format multiple times.
This implements the suggested changes described in the issue, and
refactors some of the code:
- `format_file()` is now renamed to `write_file_formatted()`, since all
it does is write to a file.
- Extract logic of formatting a single file into `format_file()`. This
means its reusable at 3 levels: formatting a single file, formatting a
package and formatting a workspace.
- Handles formatting by workspace vs package - formatting a workspace is
handled slightly differently. Formatting a package has no changes - it
still works the same. However, for workspaces, we want to format all
files at the root, then find for each subdirectories (inclusively), all
the nested directories with a manifest inside. If it exists, we are
interested in formatting it. If the subdirectory happens to have a
`swayfmt.toml` inside it, we will prioritize that configuration file.
Generally, we should prefer member config > workspace config > default.
This nuance is [explained in a
comment](https://github.com/FuelLabs/sway/pull/4038/files#diff-bf9b5d7023fff817f83ae31bd01e66d2788178a0705a2c638ce79d7990cc374aR190-R193).
- Extract logic of formatting a manifest into `format_manifest()`
It's faster by quite a bit, with some good ol' primitive testing:
new (fmt.sh):
```
for i in `seq 1 13`; do
./forc-fmt --path AMM
done
```
The above `forc-fmt` is built on `--release` and I moved it to the sway
apps repo for testing. Looped it 13 times because that's the no. of
projects in sway-applications.
old (fmt-old.sh):
```
for i in `seq 1 13`; do
forc fmt --path AMM
done
```
This one is just the current formatter.
## 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.
- [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
---------
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
Co-authored-by: Kaya Gökalp <kaya.gokalp@fuel.sh>
## Description
This PR is a subset of #3744. It introduces `DeclRef`, which is a smart
wrapper type around `DeclId` and contains additional information aside
from the `DeclId`. This allows us to make `DeclId` a copy type and
remove excessive clones of `DeclId` and `DeclRef`.
This PR is a subset of #3744, so while not explicitly necessary right
now on `master`, there will be additional fields added to `DeclRef` in
#3744.
In detail, this PR:
1. Changes `DeclId` to a copy type defined as:
```rust
#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash, Ord, PartialOrd)]
pub struct DeclId(usize);
```
2. Creates a new `DeclRef` type which is a handle to a use of a
declaration: (there will be more fields added to this in #3744)
```rust
/// A reference to the use of a declaration.
#[derive(Debug, Clone)]
struct DeclRef {
/// The name of the declaration.
name: Ident,
/// The index into the [DeclEngine].
id: DeclId,
/// The [Span] of the entire declaration.
decl_span: Span,
}
```
3. Changes the definition of the `TyDeclaration::FunctionDeclaration`
variant to contain additional fields: (there will be more fields added
to this in #3744)
```rust
FunctionDeclaration {
name: Ident,
decl_id: DeclId,
decl_span: Span,
},
```
4. Changes the definiton of the
`TyExpressionVariant::FunctionApplication` variant to contain a
`DeclRef` instead of just the previous `DeclId`. The
`TyExpressionVariant::FunctionApplication` variant gets a `DeclRef`
because `DeclRef` is a handle to a declaration _usage_, while the
`TyDeclaration::FunctionDeclaration` variant does not get a `DeclRef`
because it is simply an AST node for the function declaration. This
distinction will be more clear/necessary in #3744.
5. Changes the `DeclEngine` API to take `&T where ...`, allowing us to
remove more unnecessary instances of `.clone()`.
## 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).
- [ ] 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: emilyaherbert <emily.herbert@fuel.sh>
## Description
Collect LSP tokens for fields of enums, structs and storage field
annotations by refactoring the `TypeId` handling to use `TypeArgument`
and collect name spans.
Fix#4052Fix#4051
## 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
This adds LSP tokens with proper definitions inside type ascriptions for
variable and const declarations, function parameter type definitions and
function return type definitions.
To this end it refactors the definition handling to use `TypeArgument`s
instead of raw `TypeId`s.
Fix#3616Fix#4030
## 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: João Matos <joao@tritao.eu>
Co-authored-by: Mohammad Fawaz <mohammadfawaz89@gmail.com>
## Description
closes#3329.
This PR filters unrelevant member nodes for `forc-client` operations in
workspaces. `forc deploy` only builds contracts and `forc run` only
builds scripts. This is done by adding a filtering capability to
`forc-pkg`.
## 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
Bump to `v0.35.0` for a new release.
## 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.
With these changes `TyStructDeclaration` and `TyEnumDeclaration` now
have a call path instead of a name.
This is required before changing the JSON ABI to use enum and struct
types with call paths instead of only names which can be duplicate.
This also fixes#418 by changing `Unifier` to compare `CallPath`'s
instead of `Ident`'s for enums and structs.
Closes https://github.com/FuelLabs/sway/issues/418
---------
Co-authored-by: João Matos <joao@tritao.eu>
This is a small refactor of the `forc-client` crate in anticipation of
including the new `forc submit` command (see #3885) as a new binary
output for the crate.
This PR inverts the forc-client module hierarchy to follow `forc`'s
layout a little more closely.
It also refactors the command types in order to better share sets of
clap arguments between different commands with the aim of reducing code
duplication and providing a more uniform experience across all official
forc commands/plugins. This will be improved further once the `forc
submit` command is included, allowing us to share some of the networking
arguments too.
---------
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
Closes#3923
The name here is slightly misleading. This does clean up how we handle
it to a degree, but mostly due to a conflict of what is considered
documentable. We don't have html rendering for `ImplTrait`s just yet,
and because they were considered documentable but not handled we were
getting a panic.
While working this out, I found another bug: #3929
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
closes#3673.
## About this PR
This PR adds `CONTRACT_ID` injection while building contracts with `forc
build --test`. `CONTRACT_ID` is the id of the contract without the tests
added. To find out that id, we first compile the contract without tests
enabled.
The rough outline of stuff happening here:
1. We iterate over `BuildPlan` members to find out contracts and collect
their contract id into an injection map. In this step only the contracts
are built. To determine contract id we need to compile the contract
without tests. Since we also need the bytecode of the contract without
tests, we are collecting them as we come across them while iterating
over members.
2. With the injection map build and execute all the tests, so basically
after first step we are just doing the old `forc-test` behaviour.
So basically I added a pre-processing step for contract id collection
for those members that require it (contracts).
This enables the following test structure:
```rust
let caller = abi(MyContract, CONTRACT_ID);
let result = caller.test_function {}();
assert(result == true)
```
closes#3807.
- Moved `Log` and `LogData` formatting code from `forc-client` to
`forc-util` as `forc-test` needs it too.
- Added `--logs` and `--pretty-print` flags to `forc-test`
This PR, refactor the `BuildPlan` generation a little to be able to
re-use some of the parts from other crates that requires to create
`BuildPlan` from build opts.
On top of that this PR also introduces a way to inject list of items
into the namespace of any member of the workspace.
This is done to unblock #3729closes#3763.
This crate allows for constructing arbitrary transactions from the
command line. The constructed `forc_tx::Transaction` can be converted to
a `fuel_tx::Transaction` using the `TryFrom` implementation.
The key difference between the `forc_tx::Transaction` type differs in
that it accepts *paths* for fields like `bytecode`, `storage_slots`,
`predicate_data`, etc. These are loaded during the
`fuel_tx::Transaction`'s `try_from` constructor.
Addresses https://github.com/FuelLabs/sway/issues/3491.
Verbose Example
---------------
The following isn't a valid transaction, but shows what it looks like to
specify arguments including multiple inputs and outputs.
```console
forc tx create \
--bytecode ./my-contract/out/debug/my-contract.bin \
--storage-slots ./my-contract/out/debug/my-contract-storage_slots.json \
--gas-limit 100 \
--gas-price 0 \
--maturity 0 \
--witness ADFD \
--witness DFDA \
input coin \
--utxo-id 0 \
--output-ix 0 \
--owner 0x0000000000000000000000000000000000000000000000000000000000000000 \
--amount 100 \
--asset-id 0x0000000000000000000000000000000000000000000000000000000000000000 \
--tx-ptr 89ACBDEFBDEF \
--witness-ix 0 \
--maturity 0 \
--predicate ./my-predicate/out/debug/my-predicate.bin \
--predicate-data ./my-predicate.dat \
input contract \
--utxo-id 1 \
--output-ix 1 \
--balance-root 0x0000000000000000000000000000000000000000000000000000000000000000 \
--state-root 0x0000000000000000000000000000000000000000000000000000000000000000 \
--tx-ptr 89ACBDEFBDEF \
--contract-id 0xCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC \
input message \
--msg-id 0xBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB \
--sender 0x1111111111111111111111111111111111111111111111111111111111111111 \
--recipient 0x2222222222222222222222222222222222222222222222222222222222222222 \
--amount 1 \
--nonce 1234 \
--witness-ix 1 \
--msg-data ./message.dat \
--predicate ./my-predicate2/out/debug/my-predicate2.bin \
--predicate-data ./my-predicate2.dat \
output coin \
--to 0x2222222222222222222222222222222222222222222222222222222222222222 \
--amount 100 \
--asset-id 0x0000000000000000000000000000000000000000000000000000000000000000 \
output contract \
--input-ix 1 \
--balance-root 0x0000000000000000000000000000000000000000000000000000000000000000 \
--state-root 0x0000000000000000000000000000000000000000000000000000000000000000 \
output message \
--recipient 0x2222222222222222222222222222222222222222222222222222222222222222 \
--amount 100 \
output change \
--to 0x2222222222222222222222222222222222222222222222222222222222222222 \
--amount 100 \
--asset-id 0x0000000000000000000000000000000000000000000000000000000000000000 \
output variable \
--to 0x2222222222222222222222222222222222222222222222222222222222222222 \
--amount 100 \
--asset-id 0x0000000000000000000000000000000000000000000000000000000000000000 \
output contract-created \
--contract-id 0xCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC \
--state-root 0x0000000000000000000000000000000000000000000000000000000000000000
```
The output of this command dumps the entire `fuel_tx::Transaction`
serialized to JSON to stdout. A `-o tx.json` argument can be provided
(before the transaction type) to write the tx to a file instead.
Follow-up
---------
- Currently, the CLI is a bit unwieldy due to requiring a custom
`try_parse` constructor which is required to parse multiple trailing
input/output subcommands. This is necessary because clap doesn't appear
to allow multiple trailing subcommands by default. We should see if it's
possible to manually implement clap's Subcommand for some custom type in
a manner that allows us the same behaviour but without breaking clap's
generated CLI.
- Possibly add forc-aware defaults, i.e. infer unambiguous defaults for
bytecode, storage slots, etc from the project within the current or
parent directory.
- Base `forc-run`, `forc-deploy` transaction construction on components
from `forc-tx`.
- Add CI tests for `forc tx` command that actually constructs and
submits a transaction to a node. This might be a lot easier to write
once we have something like a `forc submit` command that allows
submitting a transaction from the command line.
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
This bootstraps the EVM backend via the following:
- [x] Add build target support. This is implemented as a `--build-target
/ --target` CLI flag in Forc.
- [x] Allow for multiple asm builders The existing architecture was
refactored to be trait-based, and the code was split into two
directories, for `fuel` and `evm` backends.
- [x] Add minimal EVM assembly output.
- [x] Add `evm` target testing support.
- [x] Implement EVM smart contract memory loader
- [x] Implement basic Solidity ABI generation
The goal of this PR is to reduce code bloat. So it does a number of
things, although there are _no functional changes_.
1. Change the canonical code name from "declaration engine" to "decl
engine", including renaming `DeclarationEngine` to `DeclEngine`,
`DeclarationId` to `DeclId`, and `DeclarationWrapper` to `DeclWrapper`.
"`Declaration`" is a lot of syllables to say all the time haha 😅
2. Rename the `DeclEngine::look_up_decl_id` method to `DeclEngine::get`
and rename the `DeclEngine::replace_decl_id` method to
`DeclEngine::replace`.
3. Rename the `DeclEngine::insert` method to
`DeclEngine::insert_wrapper`.
4. Add a new `DeclEngine::insert` method with type param `T:
Into<DeclWrapper>` and add traits for `From<DeclWrapper>` for different
declarations. Replace and remove the dedicated "`insert`" methods with
the generic `DeclEngine::insert` method.
Co-authored-by: emilyaherbert <emily.herbert@fuel.sh>
closes#3622.
closes#3586.
unblocks #3673.
## About this PR
After parsing, I added a check to remove tests from `AstTree` if tests
are not enabled. Since all the other checks are done after this
exclusion of tests, this PR also prevents warnings and errors coming
from test functions to be emitted while using `forc build`. They are
still visible with `forc test` as they should be.
A redesign of `module_prefix`. This PR introduces the `ModuleInfo`
struct with methods for auto generating paths for use in the rendering
process.
Closes#3646
Previous to this PR, `forc_pkg::check()` would only return the
`ParseProgram` and `TyProgram` AST's. In the language server, we now
also need access to the initial lexing stage produced by `sway_parse` in
order to get access to the sway keyword tokens.
This PR now returns the lexing stage of a program along with the parsed
and typed stages.
closes#3524
This PR removes the global `DeclarationEngine` in favor of keeping a
local copy in the `TypeCheckContext`.
This PR is pretty big... there aren't any additional things added other
than what I """ had to add """ in order to complete this task. At a high
level:
- This PR introduces the `Engines` struct, which has two fields
`type_engine: &TypeEngine` and `declaration_engine: &DeclarationEngine`.
- For most/many of the traits introduced in #3353, this PR changes these
traits to take a `Engines` instead of a `&TypeEngine`
Closes#2063
Co-authored-by: emilyaherbert <emily.herbert@fuel.sh>
## 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>
Looks like `cargo publish` requires that `sway.js` live inside the
`forc-doc` directory. Otherwise, the file is not found. I'm simply
moving `sway.js` to `forc-doc/src/assets` and updating the code to point
to that location instead.
This unfortunately happened because I made a non-breaking release in
`fuels-rs` that was in fact breaking. The breaking was non-breaking from
the point of view of the user, but it was breaking from the point of
view of the sway repo.
- Had to run `cargo update` to update the `fuels-rs` version
- Had to bump `fuel-core` to `0.15` due to some transitive dependencies
and conflicting types.
We now connect the edge of methods referenced in function call
expressions to the edge of the corresponding node of the implemented
trait method.
For this FunctionDeclaration was extended to keep track of the
implementing type where it is declared.
Also previously we were not correctly connecting edges in
`add_edge_from_entry` due to the function using `self.entry_points`
which is only computed as the last stage of the DCA process. Fix this by
deferring these edge node indices and only making the connection after
they are computed.
Aditionally now we use an `IdentUnique` to keep track of functions in
the CFG namespace which helps disambiguate functions shadowing each
other.
Closes https://github.com/FuelLabs/sway/issues/3067.
