## Description
This PR mainly refactors existing code around type checking and
processing of functions.
[Split type checking and namespace insertion for parameters and type
parameters](327deace24)
[Split processing of functions in two
phases.](e3cf148f3f)
I've split this up from the rest of the PR for fixing impl methods
calling to make it easier to review (also made it easier for me to find
and fix some regressions).
I also threw in another round of clippy fixes that my Rust toolchain was
complaining about.
## 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.
Updates fuel-core, fuel-vm, and other fuel-* and fuels-rs dependencies
to versions corresponding to fuel-core 0.19 release.
---------
Co-authored-by: Green Baneling <XgreenX9999@gmail.com>
## Description
closes#4667.
To be more WASM friendly and increase reuseability of `forc-util` this
PR hides fuel-tx related utilities under `fuel-tx` flag.
## Description
Waiting for:
- #4525.
@Dhaiwat10 was waiting for a release with the linked PR merged.
@IGI-111 I had the PR ready, leaving it up to you when to merge & cut
the release. Made this a major bump as we had a breaking change merged
(#4574).
## Checklist
- [ ] I have linked to any relevant issues.
- [ ] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [ ] I have requested a review from the relevant team or maintainers.
Co-authored-by: IGI-111 <igi-111@protonmail.com>
The PR fixes breakings changes from the `fuel-core 0.18.1` and `fuels-rs
0.41`.
- The `__smo` is reworked and doesn't require an output index because we
removed the `Output::Message` variant.
- Replaced the old deploy API with a new one, `Contract::deploy` ->
`Contract::load_from().deploy()`.
- The signing of the transaction and predicate id calculation requires
`ChainId` now. It breaks the API in some places. In tests, I used the
default chain id, but from the `forc` perspective we need to add the
ability to specify it.
- `fuels-signers` was renamed into `fuels-accounts`.
- We reworked `fuel_tx::Input` and now each variant of the enum has a
named type.
- Replaced all unsafe code from `fuel-crypto` with safe analog.
- On the `fuel-tx`/`fuel-core` side now, there is a difference in
whether the message contains data. If data is empty, it is `MessageCoin`
that acts like a `Coin`(has the same rules during execution). If the
data field is not empty, then it is a retryable message(or
`MessageData`). Messages like this can't be used to pay a transaction
fee, and if the execution fails, the message is not consumed(you can use
it again in the next transactions). More about them you can read in
https://github.com/FuelLabs/fuel-core/issues/946. Also, the API changed
for resources and not it is `Coins` again. Because of that, some tests
now require messages with empty data to be able to spend them.
- Removed redundant usage of `MessageId` and corresponding fields. Now
the identifier of the message is a `Nonce`.
- Removed `Output::Message`. Now you don't need to specify it in the
outputs. Because of that `SMO` opcode doesn't require a message output
index anymore.
- We unified block height(in some places it was `u32` in some `u64`) by
introducing the `BlockHeight` type.
- The `nonce` in the `Message` is a `Bytes32` now instead of
`u64`(affected `input_message_nonce` GTF).
- Reworked the handling of the `Intrinsic::Smo`. Previously `fuel-vm`
expected `smo(r1: receipt_and_message_ptr, r2: size_of_the_message, r3:
output_index, r4: amount)` but we updated that to be `smo(r1:
receipt_ptr, r2: message_ptr, r3: size_of_the_message, r4: amount)` -
according to the specification.
- Removed `input_message_msg_id` GTF.
- Now tokens should be transferred to the contract first, and after you
can transfer them via `SMO` or another transfer. So in some tests first
we need to transfer money to the contract first.
- The `fuels-rs` now generates a separate structure for encoder
`{Contract_name}Encoder`.
This PR is based on the https://github.com/FuelLabs/fuels-rs/pull/950
and causes cycle dependencies. The `fuels-rs` should be released first
and after we can apply it.
---------
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
Co-authored-by: iqdecay <victor@berasconsulting.com>
Co-authored-by: Kaya Gökalp <kaya.gokalp@fuel.sh>
See here for context:
https://github.com/FuelLabs/sway/pull/4492#issuecomment-1520949069
This follows a re-release of 0.37.1 as 0.37.3:
https://github.com/FuelLabs/sway/releases/tag/v0.37.3
The outcome of all this is that ideally, users previously on 0.37.1 will
now pull 0.37.3 next time they run `cargo update` and will not encounter
any breakage. Those ready to update can point to 0.38.0 after this is
published.
Also runs `cargo update` in order to update deps to their latest patch
release.
---------
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
Moves following `Cargo.toml` fields to workspace `Cargo.toml` so we
don't have to keep repeating ourselves:
- edition
- authors
- homepage
- license
- repository
## 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
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.
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>
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>
