## Description
- Added support for viewing emitted logs when making a transaction using
forc-call
- Added `show_receipts` param (default-false) - so we can optionally
prnt out all receipts
- The CLI output becomes too long for a call with multiple receipts;
this is a minor UI enhancement
Addresses https://github.com/FuelLabs/sway/issues/6887
## Example usage/output
```sway
script;
struct ExampleParams {
test_val: u32,
test_str: str,
test_tuple: (u32, u64),
}
fn main() -> u64 {
log("hiiii");
log(123);
log(ExampleParams { test_val: 5, test_str: "hello world", test_tuple: (1,2) });
5
}
```
<img width="986" alt="image"
src="https://github.com/user-attachments/assets/3725ff17-29c9-43d7-98cc-4cacfc213ecb"
/>
## 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] 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.
---------
Co-authored-by: z <zees-dev@users.noreply.github.com>
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
Co-authored-by: kayagokalp <kayagokalp123@gmail.com>
## Description
The following PR introduces a new forc plugin; `forc-call`.
This plugin allows users to call functions on deployed contracts using
the `forc call` command.
This is ideal for quickly querying the state of a deployed contract.
In this first implementation; the contract ABI is required (as a path to
a local JSON file or a URL to a remote JSON file).
This is inspired by the [`cast
call`](https://book.getfoundry.sh/reference/cast/cast-call) tool; which
is a popular tool for interacting with deployed contracts on Ethereum.
The implementation is based on the following Github issue:
https://github.com/FuelLabs/sway/issues/6725
In the current implementation, you can query a contract state using the
`forc call` command by providing the target contract ID, it's respective
ABI file, and the function name (selector) and arguments.
<details>
<summary>Forc Call CLI</summary>
```sh
forc call --help
```
```
Call a contract function
Usage: forc call [OPTIONS] <CONTRACT_ID> <FUNCTION> [ARGS]...
Arguments:
<CONTRACT_ID>
The contract ID to call
<FUNCTION>
The function signature to call. When ABI is provided, this should be a
selector (e.g. "transfer") When no ABI is provided, this should be the
full function signature (e.g. "transfer(address,u64)")
[ARGS]...
Arguments to pass into main function with forc run
Options:
--abi <ABI>
Optional path or URI to a JSON ABI file
--node-url <NODE_URL>
The URL of the Fuel node to which we're submitting the transaction. If
unspecified, checks the manifest's `network` table, then falls back to
`http://127.0.0.1:4000`
You can also use `--target`, `--testnet`, or `--mainnet` to specify the
Fuel node.
[env: FUEL_NODE_URL=]
--target <TARGET>
Use preset configurations for deploying to a specific target.
You can also use `--node-url`, `--testnet`, or `--mainnet` to specify
the Fuel node.
Possible values are: [local, testnet, mainnet]
--testnet
Use preset configuration for testnet.
You can also use `--node-url`, `--target`, or `--mainnet` to specify the
Fuel node.
--mainnet
Use preset configuration for mainnet.
You can also use `--node-url`, `--target`, or `--testnet` to specify the
Fuel node.
--signing-key <SIGNING_KEY>
Derive an account from a secret key to make the call
[env: SIGNING_KEY=]
--wallet
Use forc-wallet to make the call
--amount <AMOUNT>
Amount of native assets to forward with the call
[default: 0]
--asset-id <ASSET_ID>
Asset ID to forward with the call
--gas-forwarded <GAS_FORWARDED>
Amount of gas to forward with the call
--mode <MODE>
The execution mode to use for the call; defaults to dry-run; possible
values: dry-run, simulate, live
[default: dry-run]
--gas-price <PRICE>
Gas price for the transaction
--script-gas-limit <SCRIPT_GAS_LIMIT>
Gas limit for the transaction
--max-fee <MAX_FEE>
Max fee for the transaction
--tip <TIP>
The tip for the transaction
--external-contracts <EXTERNAL_CONTRACTS>
The external contract addresses to use for the call If none are
provided, the call will automatically extract contract addresses from
the function arguments and use them for the call as external contracts
-h, --help
Print help (see a summary with '-h')
-V, --version
Print version
```
</details>
### Example usage
```sh
forc call 0xe18de7c7c8c61a1c706dccb3533caa00ba5c11b5230da4428582abf1b6831b4d --abi ./out/debug/counter-contract-abi.json add 1 2
```
- where
`0xe18de7c7c8c61a1c706dccb3533caa00ba5c11b5230da4428582abf1b6831b4d` is
the contract ID
- where `./out/debug/counter-contract-abi.json` is the path to the ABI
file
- where `add` is the function name (selector)
- where `1 2` are the arguments to the function
^ the sway code for the add function could be:
```sway
contract;
abi MyContract {
fn add(a: u64, b: u64) -> u64;
}
impl MyContract for Contract {
fn add(a: u64, b: u64) -> u64 {
a + b
}
}
```
## Implementation details
1. The provided ABI file downloaded (unless local path is provided)
2. The ABI is parsed into internal representation
3. The provided function selector e.g. `add` is matched with the
extracted functions from the ABI
4. The provided arguments are parsed into the appropriate types which
match the extracted function's inputs
5. The function selector and args are then converted into the `Token`
enum, which is then ABI encoded as part of the `ContractCall` struct
6. The `ContractCall` struct is then used to make a request to the node
to call the function
7. The response is then decoded into the appropriate type (based on
matched function's output type)
^ In the implementation, we don't use the `abigen!` macro since this is
a compile time parser of the ABI file; instead we make use of the lower
level encoding and decoding primitives and functions from the [Rust
SDK](https://github.com/FuelLabs/fuels-rs).
## Live example on testnet
### Example 1
The example contract above with `add` function has been deployed on
testnet - with ABI file available
[here](https://pastebin.com/raw/XY3awY3T).
The add function can be called via the CLI:
```sh
cargo run -p forc-client --bin call -- \
--testnet \
--abi https://pastebin.com/raw/XY3awY3T \
0xe18de7c7c8c61a1c706dccb3533caa00ba5c11b5230da4428582abf1b6831b4d \
add 1 2
```
### Example 2 - get `owner` of Mira DEX contract
```sh
cargo run -p forc-client --bin call -- \
--testnet \
--abi https://raw.githubusercontent.com/mira-amm/mira-v1-periphery/refs/heads/main/fixtures/mira-amm/mira_amm_contract-abi.json \
0xd5a716d967a9137222219657d7877bd8c79c64e1edb5de9f2901c98ebe74da80 \
owner
```
Note: Testnet contract address
[here](https://docs.mira.ly/developer-guides/developer-overview#testnet-deployment)
## Encoding of primitive types
When passing in function arguments, the following types are encoded as
follows:
| Types | Example input | Notes |
|-----------------------------------------------|----------------------------------------------------------------------|------------------------------------------------------------------------------------------------|
| bool | `true` or `false` | |
| u8, u16, u32, u64, u128, u256 | `42` | |
| b256 |
`0x0000000000000000000000000000000000000000000000000000000000000042` or
`0000000000000000000000000000000000000000000000000000000000000042` |
`0x` prefix is optional |
| bytes, RawSlice | `0x42` or `42` | `0x` prefix is optional |
| String, StringSlice, StringArray (Fixed-size) | `"abc"` | |
| Tuple | `(42, true)` | The types in tuple can be different |
| Array (Fixed-size), Vector (Dynamic) | `[42, 128]` | The types in
array or vector must be the same; i.e. you cannot have `[42, true]` |
| Struct | `{42, 128}` | Since structs are packed encoded, the attribute
names are not encoded; i.e. `{42, 128}`; this could represent the
following `struct Polygon { x: u64, y: u64 }` |
| Enum | `(Active: true)` or `(1: true)` | Enums are key-val pairs with
keys as being variant name (case-sensitive) or variant index (starting
from 0) and values as being the variant value; this could represent the
following `enum MyEnum { Inactive, Active(bool) }` |
<details>
<summary>Encoding cheat-sheet</summary>
A few of the common types are encoded as follows:
| Types | Encoding Description | Example |
|--------------------------------------------|--------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------|
| bool, u8 | Encoded as a single byte. `bool`: 0x00 (false) or 0x01
(true); `u8` is the byte itself. | `bool(true) = 0x01`, `u8(42) = 0x2A`
|
| u16 | 2-byte, big-endian | `u16(42) = 0x002A` |
| u32 | 4-byte, big-endian | `u32(42) = 0x0000002A` |
| u64 | 8-byte, big-endian | `u64(42) = 0x000000000000002A` |
| u128 | 16-byte, big-endian | `u128(42) =
0x0000000000000000000000000000002A` |
| u256, b256 | 32-byte value. For u256: big-endian integer; For b256:
raw 32 bytes | `u256(42) = 32-bytes ending with ...0000002A`, `b256(...)
= exactly the 32-byte array` |
| Tuples, Arrays, Structs (Fixed-size) | Concatenate the encodings of
each element/field with no extra padding | `(u8(1), bool(true)) = 0x01
0x01`; `[u16;2]: [42,100] = 0x002A0064`; `struct {u8,u8}: 0x0102` |
| Enums | `u64` variant index + encoded variant data with no extra
padding | `MySumType::X(42): 0x0000000000000000 000000000000002A` |
| Bytes, String, RawSlice, Vector (Dynamic) | `u64` length prefix + raw
data, no padding | `"abc" = length=3: 0x0000000000000003 0x61 0x62 0x63`
|
^ This is based on the docs here:
https://docs.fuel.network/docs/specs/abi/argument-encoding
</details>
## Future improvements
1. Support for function signature based calls without ABI
2. Support for raw calldata input
3. Function selector completion - given ABI 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).
- [ ] 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).
- [x] I have requested a review from the relevant team or maintainers.
---------
Co-authored-by: zees-dev <zees-dev@users.noreply.github.com>
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
This PR adds support for deploying executables, namely predicates and
scripts. Before this PR executing `forc-deploy` on a script or predicate
was an hard error. With this PR we are enabling the deployment of them
via converting them to a loader which loads the original bytecode
deployed as a blob.
The loader binaries are serialized to disk under `out` folder for both
predicates and scripts. For predicates we also save the root of the
loader additionally. Every output related to generated `loader` is
suffixed with `-loader` so that it can be distinguished easily.
---------
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
## Description
For #6179, PR #6501 kept bumping into errors as it was doing too many
things, so I've split that PR into multiple PRs. This is the first, and
the only thing it does is move all of the various `Cargo.toml`
dependencies into the single workspace `Cargo.toml`.
Future PRs will:
- Update dependency versions
- Update code that breaks from the version bumps
## 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
To be merged after https://github.com/FuelLabs/sway/pull/6250
## 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.
---------
Co-authored-by: Brandon Kite <brandonkite92@gmail.com>
Co-authored-by: IGI-111 <igi-111@protonmail.com>
## Description
Includes critical fix https://github.com/FuelLabs/sway/pull/6212
## 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
Update clap and deps to latest version
## 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
Base asset ids are dynamic for the newer fuel-core versions. This PR
adds capability to query that and use it for forc-client transactions.
Also adds a flag `max-fee` which is required to be set for newer
versions of fuel-core.
## Description
Bumps fuel-core to v0.26.0, for some reason sway-core was failing and
needed a blanket implementation for `Vec<T: PartialEqWithEngines>`
## Description
Add macro to test argument parsing rather than testing the external
command through building and spawning a separated process. This is an
improved version of #5519
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
Bumps repo to 0.49.0, made this a major one after some thought as we
longer support beta-4 as tooling with this release.
Also ran `cargo update` as this is a breaking change
---------
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
related to #5463
Fixes std dependency on released std for forc-doc, forc-fmt and forc-tx
test projects used in cli tests which breaks release structure.
## Description
Fixes#5398, #5374
Add examples to our `--help` cli. The examples are defined through the a
macro `forc::cli_examples { }` and each of these examples is part of the
the test suite of the crate. This is done to ensure the documentation is
always up to date or updated whenever the tests are not passing.
## 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: Braqzen <103777923+Braqzen@users.noreply.github.com>
## Description
co-developed with: @IGI-111 and @xgreenx
This PR adds support for transaction policies.
What was done:
- bump `fuel-vm` to `0.43.1`
- bump `fuels-rs` to `0.53.0`
- update the `std-lib` to handle new `GTF` codes and the transaction
policies
- update all test
BREAKING CHANGE:
- removed `TxParameters` in favor of `TxPolicies`
- changed `gtf` opcodes
- removed `Mint` from `forc-tx` and cli
## Checklist
- [ ] I have linked to any relevant issues.
- [ ] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
---------
Co-authored-by: green <xgreenx9999@gmail.com>
Co-authored-by: Elvis <elvisdedic@outlook.com>
Co-authored-by: IGI-111 <igi-111@protonmail.com>
Co-authored-by: xunilrj <xunilrj@hotmail.com>
Co-authored-by: Vaivaswatha Nagaraj <vaivaswatha.nagaraj@fuel.sh>
Co-authored-by: Kaya Gökalp <kaya.gokalp@fuel.sh>
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
## Description
Closes https://github.com/FuelLabs/sway/pull/4974
Added the beta-4 target and updated documentation (from
https://github.com/FuelLabs/sway/pull/4974)
Refactored part of forc-deploy and added unit tests.
- No longer mutating the Command, so the Command is always whatever the
user gave us
- Using the default values from the node itself via API call, rather
than hardcoded constants
- The values of `Gas` are now optional, so we only override them when
the user hasn't specified anything
Other changes:
- deployment works using the urls without `/graphql` prefixes, so I
updated the constants to remove the prefix. This is shown to the user
and it looks cleaner without it.
- Added coloring and consistent styling for errors and warnings to
printed to the console. It looks like this now (previously no color)
- `deploy`, `run`, and `submit` all now have the same options for
specifying the node (node_url, testnet, and target), capture in the
`TargetNode` struct. They use the same helper functions to extract the
node url and determine gas limit & price.
## 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: kayagokalp <kaya.gokalp@fuel.sh>
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## 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.
