This is in preparation for the argument mutability analysis. This PR
also has some skeleton code for this analysis, but the actual analysis
is still a `todo!()`.
The analysis will also have better precision if we use fewer asm blocks,
but I'll get to that after working on the analysis itself.
## Description
This PR contains an initial implementtion of subroutine calls using the
in-progress [jump-and-link instruction
`JAL`](https://github.com/FuelLabs/fuel-specs/pull/630). It
substantially reduces the function call overhead: the old code used 4
instructions per call, while the new version uses 1-3 depending on the
distance to the called function.
### Future optimizations
* Reorder functions, so those that call each other are adjacent
* Use absolute or IS-relative jumps where it makes sense, see
https://github.com/FuelLabs/sway/issues/7267
## 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)
- [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.
The goal of this PR is to enable the check in the IR verifier to ensure
that the operand to `ptr_to_int` instructions can only be pointers. The
other changes are to support that.
## Description
Stabilize the `error_type` feature.
Fixes#6765
## 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: Igor Rončević <ironcev@hotmail.com>
## Description
Bumps fuel-vm, fuel-core fuels-rs and forc-wallet to latest versions.
Upgrades Rust to 2021 edition.
## 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.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- I believe this is non-breaking from user code perspective but I'm not
too sure about that
- [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: z <zees-dev@users.noreply.github.com>
Co-authored-by: zees-dev <63374656+zees-dev@users.noreply.github.com>
Co-authored-by: JoshuaBatty <joshpbatty@gmail.com>
Co-authored-by: IGI-111 <igi-111@protonmail.com>
## Description
This PR:
- optimizes the existing `std:#️⃣:Hash` implementations in the `std`,
for bytecode size and gas usage. The optimizations are based on
eliminations of intensive memory allocations and memory copying. On a
sample application, the **bytcode size reduction was ~10%**, and the
**gas usage reduction >50%**. The detailed results are presented below.
- fixes#7234
- adds `Hash` implementations for:
- unit type `()`,
- tuples of a single element `(T, )`,
- empty arrays `[T; 0]`,
- other `std` types that were missing `Hash` implementations, like,
e.g.: `Duration`, `Time`, `U128`, `B512`, etc. Note that `Hash`
implementations were not provided for various Error enums.
## Performance Optimizations
To measure performance gains, a sample application was used, that:
- hashed all built-in types individually, as well as tuples and array of
those, and `Bytes` and `Vec`.
- hashed all the above types within a same `Hasher`, simulating hashing
of complex types like, e.g., structs.
The bytcode size of the sample application got **reduced from 9560 to
8584 bytes (10.21% reduction)**.
The overall gas usage for hashing types individually **got reduced from
35826 to 15562 (56.56% reduction)**.
The overall gas usage for hashing types within a same `Hasher` **got
reduced from 34951 to 14443 (58.67% reduction)**.
The `in_language` tests for hashing, `hash_inline_tests`, also
demonstrated a **significant reduction in gas usage, up to 57.82%**. A
small regression is noticable when hashing empty types, e.g., unit. We
expect that regression also to disappear once `const fn` is implemented,
and local constants could be evaluated from generic functions.
<details>
<summary>Expand to see the detailed gas cost comparison for all
`hash_inline_tests`</summary>
| Test | Before | After | Percentage |
|------|--------|-------|------------|
| hash_address | 10070 | 6366 | 36.78% |
| hash_array_10 | 33691 | 15867 | 52.90% |
| hash_array_1 | 4870 | 3102 | 36.30% |
| hash_array_2 | 8069 | 4517 | 44.02% |
| hash_array_3 | 11219 | 5883 | 47.56% |
| hash_array_4 | 14369 | 7249 | 49.55% |
| hash_array_5 | 17519 | 8615 | 50.82% |
| hash_array_6 | 20917 | 10229 | 51.10% |
| hash_array_7 | 24109 | 11637 | 51.73% |
| hash_array_8 | 27302 | 13046 | 52.22% |
| hash_array_9 | 30494 | 14454 | 52.60% |
| hash_array_empty | 773 | 777 | -0.52% |
| hash_asset_id | 10070 | 6366 | 36.78% |
| hash_b256 | 9604 | 5900 | 38.57% |
| hash_b512 | 6028 | 4476 | 25.75% |
| hash_bool | 3885 | 1993 | 48.70% |
| hash_bytes | 8200 | 7112 | 13.27% |
| hash_call_params | 11439 | 6019 | 47.38% |
| hash_contract_id | 10070 | 6366 | 36.78% |
| hash_duration | 4753 | 2985 | 37.20% |
| hash_ed25519 | 18268 | 14780 | 19.09% |
| hash_evm_address | 10098 | 6394 | 36.68% |
| hash_fn_sha256_str_array | 1953 | 1167 | 40.25% |
| hash_hasher_write_str | 2512 | 2013 | 19.86% |
| hash_hasher_write_str_array | 2306 | 1807 | 21.64% |
| hash_identity | 30526 | 14998 | 50.87% |
| hash_input | 11766 | 5718 | 51.40% |
| hash_message | 3003 | 3099 | -3.20% |
| hash_option | 21373 | 9511 | 55.50% |
| hash_output | 19649 | 9569 | 51.30% |
| hash_point2d | 6861 | 4801 | 30.02% |
| hash_public_key | 7372 | 7692 | -4.34% |
| hash_result | 27083 | 11423 | 57.82% |
| hash_scalar | 4159 | 3313 | 20.34% |
| hash_secp256k1 | 18268 | 14780 | 19.09% |
| hash_secp256r1 | 18268 | 14780 | 19.09% |
| hash_signature | 31213 | 16936 | 45.74% |
| hash_str | 6902 | 5417 | 21.52% |
| hash_string | 5453 | 5252 | 3.69% |
| hash_time | 4753 | 2985 | 37.20% |
| hash_transaction | 23604 | 11508 | 51.25% |
| hash_tuple_1 | 4834 | 3066 | 36.57% |
| hash_tuple_2 | 7997 | 4445 | 44.42% |
| hash_tuple_3 | 11147 | 5811 | 47.87% |
| hash_tuple_4 | 14297 | 7177 | 49.80% |
| hash_tuple_5 | 17447 | 8543 | 51.03% |
| hash_u128 | 7943 | 4391 | 44.72% |
| hash_u16 | 9384 | 5860 | 37.55% |
| hash_u256 | 9600 | 5896 | 38.58% |
| hash_u32 | 9384 | 5860 | 37.55% |
| hash_u64 | 9372 | 5836 | 37.73% |
| hash_u8 | 7740 | 3704 | 52.14% |
| hash_unit | 771 | 775 | -0.52% |
| hash_vec | 53077 | 33733 | 36.45% |
</details>
## Breaking Changes
Strictly seen, adding `Hash` implementations for `std` types like
`Option<T>` represents a breaking change for those who eventually had
their own implementations. However, if such implementations existed,
after introducing strict trait coherence checks, they already became
invalid, because neither the `Hash` trait nor the types `Hash` is
implemented for are part of third party packages, but contained within
the `std`.
Thus, we can have a breaking change only if someone migrates from an
older version that does not have trait coherence in place. But in that
case, the trait coherence itself will already report breaking change
errors.
Because `Hash` implementations for `std` types must and should have
already been provided within the `std`, we can treat adding those
implementations as a bug fix.
## 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.
- [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 is the third PR to address #6351. It allows safely taking addresses
of function arguments, and represents references (`&`) as pointers in
the IR.
Note: The entire function `type_correction` (in `ir_generation.rs`) and
this
[edit](2de7ab9ec1 (diff-3b0502f41aeb3c45ddbdb3cc590658d73d2bd7283671eb6d789d7e77a7dd2596R670))
in `compile.rs`, to handle return values, must be removed once we fix
and finalize the syntax of references. Until then these two hacks need
to stay. Ideally I wanted to put them both in one place (which is the
`type_correction` pass), but the return type fix needs to happen,
unfortunately, during IR gen.
---------
Co-authored-by: IGI-111 <igi-111@protonmail.com>
Co-authored-by: Igor Rončević <ironcev@hotmail.com>
## Description
This PR removes the double compilation of contract methods in the IR, in
the case of new encoding.
The contract methods were first compiled as a part of the compilation of
the `__entry` function, and afterwards, again separately. The contract
methods compiled in the second compilation pass were later on removed as
not reachable.
The issue was brought to the surface in a test written by @hal3e in
[fuel-rs PR that integrates ABI
errors](https://github.com/FuelLabs/fuels-rs/pull/1651). In that
particular test, because of the double compilation, a `panic` expression
in a contract method got compiled twice and produced two same entries in
the ABI JSON.
Removing the double compilation resulted in a small reduction of
bytecode size and gas usage. In some tests bytecode size got reduced for
~50 bytes and the gas usage for ~30 gas units.
Additionally, the PR adjusts the printing of IR global variables, to be
the same as printing of configurables and locals, without the spaces
between individual entries.
## 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).
- [ ] 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.
- [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 PR adds an initial support to symbolic fuel-vm interpretation to
improve codegen. The symbolic execution is designed to be extended in
later PRs. In it's current form, it provides three distinct
improvements:
1. If a temporary (allocated) register contains a value already held in
another register, we can use that other register instead. This reduces
register pressure, and removes unnecessary `mov` ops.
2. If a register already has the value we're setting it to, we can
eliminate the instruction doing so.
3. For conditional jump instructions, if the value of the condition is
known, one of the branches can be elminated. In such cases, the
instruction is either removed or replaced with an unconditional jump.
Dead code elimination pass can then potentially remove the
now-unreachable branch.
In addition to these changes, this PR takes the optimization level into
account for asm generation. For debug builds, we only run the
optimization passes once. But for release builds we run the optimization
passes multiple times, until we either cannot eliminate any more
operations, or until a fixed upper limit of rounds. For instance, this
means that if the new pass added in this PR manages to eliminate a
branch, and then dead code elimination removes that code, it could allow
the interpretation pass to do even more work.
To account for new optimization passes, I also organized them to mulple
files, so that the ones which create private types are scoped well and
thus easier to read.
## Impact
project | size before | size after | size reduction
-|-|-|-
mira-v1-core | 89.384 KB | 83.480 KB | 6.6%
## 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). No changes required!
- [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. Just updated pre-existing ones!
- [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: Vaivaswatha N <vaivaswatha.nagaraj@fuel.sh>
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
Updates the fuels version to `0.71`, and the `fuel-vm` crates to
`0.59.2`
Also closes: https://github.com/FuelLabs/sway/issues/6976
Co-authored-by: z <zees-dev@users.noreply.github.com>
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
This PR promotes the following experimental features to standard ones:
- #6701
- #6883
- #6994
- #7006
Additionally, the PR stenghtens the migration infrastructure by checking
some additional cases in selecting corresponding typed elements in
desugared code which were not checked before.
Closes#6701.
Closes#6883.
Closes#6994.
Closes#7006.
## 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.
- [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
Merges the two libraries. They were initially separate to separate the
core logic and fuel vm specific functionality, but that separation is no
longer maintained so having a merged library is better.
Closes#6708
## 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: Sophie <47993817+sdankel@users.noreply.github.com>
Co-authored-by: Igor Rončević <ironcev@hotmail.com>
## Description
Closes https://github.com/FuelLabs/sway/issues/6990
The main change here is switching from using the data section offset to
using the configurables offset in the blob loader in forc-deploy.
TODO: update the loader-abi.json test file(s) once deployment to testnet
is working.
## 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
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
Updated the `fuels-rs` SDK to `0.77`.
This required updating transitive dependencies to the relevant versions
specified in fuels-rs sdk.
## Dependency tree
```mermaid
graph TD
sway[sway]
fuelsrs[fuels-rs]
fuelabi[fuel-abi-types]
fuelvm[fuel-vm]
forcwallet[forc-wallet]
fcoreclient[fuels-core]
fvmprivate[fuel-vm-private]
%% Main dependency relationships
sway --> fuelsrs
fuelsrs --> fuelabi
fuelsrs --> fuelvm
fuelsrs --> forcwallet
fuelsrs --> fcoreclient
%% Secondary dependencies
fcoreclient --> fvmprivate
fvmprivate --> fuelvm
%% forc-wallet dependencies
forcwallet --> fuelvm
forcwallet --> fuelsrs
%% Styling
classDef primary fill:#d0e1f9,stroke:#4a90e2,stroke-width:2px
classDef secondary fill:#e8f4ea,stroke:#66b366,stroke-width:2px
class sway,fuelsrs primary
class fuelabi,fuelvm,forcwallet,fcoreclient,fvmprivate secondary
%% Add notes
subgraph Note
note[Update forc-wallet first due to circular dependency]
style note fill:#fff4e6,stroke:#ffab40,stroke-width:1px
end
```
## 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: z <zees-dev@users.noreply.github.com>
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
Co-authored-by: hal3e <git@hal3e.io>
## Description
SIgnificantly reduces bytecode sizes by transforming the following
commonly-used operations when the constant value fits into the immediate
part of the `*i` variant of the instruction:
* `MOVI(tmp, copy_len); MCP(dst, src, tmp)` → `MCPI(dst, src, copy_len)`
(in `compile_mem_copy_bytes`)
* `MOVI(dst, offset); ADD(dst, dst, DATA_SECTION)` → `ADDI(dst,
DATA_SECTION, offset)` (in `addr_of`)
## Checklist
- [ ] I have linked to any relevant issues. (none that I know of)
- [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). (no changes required)
- [ ] 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. (partially; some values in tests got smaller. we don't
seem to be tracking the size and size regressions in tests)
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant. (not 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:
Fixed errors and inaccuracies in the project's textual materials.
Type of Change:
Fixing errors (typos, grammatical mistakes, etc.)
Testing:
Changes have been reviewed to ensure no new errors were introduced.
Impact:
Improved readability of texts and documentation.
Additional Notes:
Regular text audits are recommended to maintain a high standard of
quality.
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
## Description
This PR improve value propagation optimization in two ways:
1 - First, when the optimizer knows that both source and destination
registers of the `MOVE` instruct have the same value and version; it
will remove the instruction as it is useless;
2 - Otherwise, we propagate the value saying that destination now have
the same value and version of the source register for other
optimizations.
## 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.
Re-enabling this feature after a bugfix. (reverted PR: #6522)
---------
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
Co-authored-by: IGI-111 <igi-111@protonmail.com>
The preamble now contains 8 bytes of offset to the configurables
section. If there is no configurable const in the data-section, then the
value of this integer will be equal to the size of the binary itself.
This also means that we now sort the data-section to have all the
non-configurables first, and then the configurables.
The preamble final asm looks like this (the offset to configurables is
0'd out here in the example):
```
;; ASM: Final program
;; Program kind: Script
.program:
move $$tmp $pc
jmpf $zero i10
DATA_SECTION_OFFSET[0..32]
DATA_SECTION_OFFSET[32..64]
CONFIGURABLES_OFFSET[0..32]
CONFIGURABLES_OFFSET[32..64]
lw $$ds $$tmp i1
add $$ds $$ds $$tmp
```
The preamble bytecode looks like this:
```
0x00000000 MOVE R60 $pc ;; [26, 240, 48, 0]
0x00000004 JMPF $zero 0xa ;; [116, 0, 0, 10]
0x00000008 ;; [0, 0, 0, 0, 0, 0, 2, 40]
0x00000010 ;; [0, 0, 0, 0, 0, 0, 0, 0]
0x00000030 LW R63 R60 0x1 ;; [93, 255, 192, 1]
0x00000034 ADD R63 R63 R60 ;; [16, 255, 255, 0]
...
```
---------
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
Co-authored-by: IGI-111 <igi-111@protonmail.com>
## Description
This PR improves `fn_dedup` to also deduplicate config decode functions.
Given how early this optimization was running, some optimizations were
being lost, because some functions only get identical at the final IR. I
believe we chose to run this early to decrease the pressure in other
passes, but to allow this pass to really coalesce decodes I think makes
sense to run it again at the end.
I am also deleting from the IR functions that were being replaced. This
allowed the new test to decrease around 100 bytes. Our old configurable
test went from 7600 to 7250 bytes.
## 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).
- [ ] 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).
- [ ] I have requested a review from the relevant team or maintainers.
---------
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
Co-authored-by: IGI-111 <igi-111@protonmail.com>
Co-authored-by: Kaya Gökalp <kaya.gokalp@fuel.sh>
## Description
## 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: Alfie John <alfie@alfie.wtf>
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
Thanks a lot to @hal3e for helping debug this.
With this PR, there will be an additional abi in the `out` folder for
predicates and scripts that are deployed as loaders following the
`{package_name}-loader-abi.json` naming convention.
This PR adds `loader-abi.json` file generation capability to forc. To do
so forc needs to have the old (original) and new (loader) data offsets
of the script/predicate. After getting it the difference should be
applied to all configurable slots to find out the new locations of the
configurable slots inside the loader binary.
Basically enables backwards compatibility with the older sdk releases.
Since forc can now generate a loader abi with correct configurable
offsets, it can be used to load the script as it is, (without the newer
loader stuff) and everything will be still working.
## 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
Fixes an issue where storage access wasn't working for proxied
contracts. The fix is passing the combined storage slots to the proxy
contract.
## 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
closes#6560.
closes#6559.
This PR adds AWS kms signer support. Which is enabled if
`--aws-kms-signer <ARN>` is present. If that is the case, an aws client
is created which is used to create a AwsSigner.
With this PR, we are able to supply a signing arn and with that we can
sign a transaction. This enables being able to revoke signing authority
for aws kms managed keys. So we can control deployments and owner/target
changes for a proxy contract. Effectively enabling multi-sig like proxy
contracts via aws kms.
Edit: Added a usage video for deploying a contract with proxy and
updating it while using a aws kms signer below:
https://github.com/user-attachments/assets/de26edb0-bbbb-4894-afa0-3fe50fba74cb
---------
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
As part of #6179, this PR updates the remaining quick-fix crates to
their latest X.Y versions. Code fixes were needed to get compilation
working and tests passing.
Issue #6536 lists the crates that will need a bit more work to get
working and 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] 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
closes#6558.
This PR fixes an issue with the forc-client build script that causes the
deployment tests to be updated manually for each proxy abi change. This
is a follow up on #6535 and was overlooked in that one. Not critical as
it does not break anything on the user side but rather an code-quality
issue.
## Description
This PR implements the `__contract_ret` as a diverging (returning `!`)
and accordingly the FuelVM `retd` instruction as being a terminator.
This strict semantics is needed in the #6351 which introduces strict(er)
verification of IR invariants.
## 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
Adds more tests to chunking, and also indirectly to SDK decoding.
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
## Description
This PR adds chunk deployment based on LDC. Contracts larger than 100 kb
size, is split into chunks and chunks are deployed as `blobs`. Out of
these blobs we create a loader contract, which loads all the blobs using
`LDC` opcode.
One important thing is that this feature works nicely with the proxy
feature introduced in #6069, so a large contract, with proxy can be
deployed directly. Large contract will be split into chunks, chunks will
get deployed, loader will get get generated and deployed, after all
these a proxy contract is deployed and pointed to the loader contract
deployed.
Simple chunked deploy, chunked deployment re routing the call, chunked
deployment behind a proxy re routes the call is tested.
---------
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
## Description
Updates all the dependencies for the current release.
Implements the fuel ABI generation changes proposed in
https://github.com/FuelLabs/fuel-specs/pull/599.
Removes the flag `--json-abi-with-callpaths` and the behavior is as if
it were true. We removed the flag because it is unsafe to produce JSON
ABIs without callpaths, so we shouldn't allow it.
Includes the LDC, BSIZ, BLDD and ED19 changes
from:https://github.com/FuelLabs/sway/pull/6409.
Fixes https://github.com/FuelLabs/sway/issues/5954
Fixes https://github.com/FuelLabs/sway/issues/5151
## 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.
- [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: Vaivaswatha Nagaraj <vaivaswatha.nagaraj@fuel.sh>
Co-authored-by: Kaya Gokalp <kayagokalp123@gmail.com>
Co-authored-by: Kaya Gökalp <kaya.gokalp@fuel.sh>
Co-authored-by: Igor Rončević <ironcev@hotmail.com>
Co-authored-by: IGI-111 <igi-111@protonmail.com>
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
## Description
The current `forc deploy` command is designed to submit and await for
transaction finalization as much this is a common use case, for delayed
transactions, were transaction are submitted but can take time a lot of
time to be included and finalized. For this use cases I have implement a
suggestion `--submit-only` this will follow the current flow, but only
submit the transaction.
### Example use case for delayed transactions
In Bako Safe, as it is a multisig, it is necessary to have signatures
from multiple accounts before sending the transaction to the network. To
work together with forc deploy, a GraphQL Proxy has been developed that
works with the Fuel provider to allow sending the transaction to our
protocol.
```zsh
forc deploy --node-url 'https://api.bako.global/v1/graphql' --default-signer --submit-only
```
## Changes
- [x] Add a new deploy params `--submit-only`
- [x] Create a branch on the code to verify if the param is provided
- [x] Abstract create artifacts to a single function to avoid code
repetition
- [x] Modified transaction submission to allow for immediate submission
when the `submit_only` command is provided
- [x] Implemented tests for the new command
## Checklist
- [ ] 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).
- [ ] 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: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
Co-authored-by: K1-R1 <77465250+K1-R1@users.noreply.github.com>
## Description
Part of #6068.
This PR adds couple of things:
1. A default proxy contract implementation taken from [sway
standards](https://github.com/FuelLabs/sway-standards/blob/master/standards/src/src14.sw).
2. Infra for creating, building and deploying the reference
implementation for proxy contracts.
3. Deployment procedure such that proxy contract is deployed while
working on a contract which enables the `[proxy]` in its forc.toml. In a
way that it is owned by the deployer and the target initially points to
implementation contract.
4. Infra for making a contract call into the already deployed proxy
contracts to update their targets.
5. Adds a `Building` text to the all forc build invocations to better
inform the user about what forc is doing behind the scenes.
6. Removes duplicate forc-wallet password prompts which was very
frustrating for the users. Now forc-wallet deployment path only asks for
password once.
7. Refactors around how secret_key is selected based on user input
8. Updated docs around forc-client
9. Docs around how to use the proxy feature
## How this works
If the user does not have a proxy table in their forc.toml, nothing
changes, same old deployment procedure is followed. Only difference is
that this PR improves the ux by removing the need of providing the
password multiple times.
If the user has a contract with a proxy table but without an address
like:
```TOML
[project]
authors = ["kaya"]
entry = "main.sw"
license = "Apache-2.0"
name = "impl-contract"
[dependencies]
[proxy]
enabled = true
```
Forc automatically creates a proxy contract based on the reference
implementation at
[SRC14](61fd4ad8f6). Sets its
target to the implementation contract, whichever contract enabled the
proxy and the owner to the deployer (signing account of the
transaction).
If the user has a contract with a proxy table and an address specified
like:
```TOML
[project]
authors = ["kaya"]
entry = "main.sw"
license = "Apache-2.0"
name = "impl-contract"
[dependencies]
[proxy]
enabled = true
address = "........."
```
Forc automatically makes a set target conract call to update the proxy
contract's target. Pointing it to the newly deployed impl contract which
defines the proxy table.
Generated proxy contract abi and bins are stored at
`~/.forc/.generated_proxy_contracts/project_name` for housekeeping.
## Description
Improves the UX for forc-deploy in the following ways:
- uses `dialoguer` for a nicer interface for entering password,
selecting the wallet account from the list, and agreeing to sign.
- displays the account information in a single line, with the ETH value
shown rather than the raw gwei, similar to the browser wallet
- only shows the base asset amount for accounts, rather than all assets,
since only base asset can be used for gas fees.
- for multiple-contract deployments, users now only have to choose the
account and confirm once
- added error handling for the case where multi-contract deployments
have different networks specified in their manifests
- Displays the network URL *before* deployment rather than after
- After deployment, links to the contract and block in the block
explorer rather than just showing the ID
### Single contract deployed
### Multiple contracts deployed (workspace)
## 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 fixes a problem with `std::Bytes`, `std::Vec` and `std::String`
buffer ownership. It also fixes a problem with buffer overflow when
encoding huge types.
## Buffer Ownership
Currently, types like `Bytes`, `Vec` and `String` do not guarantee
ownership of their buffer. That means that we can very easily alias the
underlying buffer and change its mutability by simply creating a new
instance.
For example:
```sway
let some_slice = ...;
let buffer = Bytes::from(some_slice);
let mut buffer2 = buffer.clone();
// Now I can change `some_slice`
```
## Type Inference bug
I also had to fix a small problem with the type inference of method
applications. The problem is that sometimes the type check does not
return an error on the first pass, but the type is still not concrete.
For example `x.get(0) == Some(2)`, becomes `eq(x.get(0), Some(2))`.
After the first pass, `x.get(0)` is correctly inferred to be
`Option<u8>`; but `Some(2)` is only typed as `Option<Numeric>`. This
happens because the first pass starts with `TypeInfo::Unknown`. We can
use the argument types here because they may still be non-concrete types
like "Self".
What the fix is doing is that it checks if the inferred type
`is_concrete`, assuming that `Numeric` is not. This will make "Some(2)"
be type-checked again at the second pass, after monomorphization and be
correctly typed as "Option<u8>".
## IR Verification errors
This PR also improves the error message for IR verification. Now the
error is shown inside the printed IR.
## Script to update contract-ids (optional)
At `test/update-contract-ids.sh` there is a small script that
automatically updates contract ids. Unfortunately, given the indirect
nature of contract calls, it is impossible for the script to know which
contract it needs to compile. So we need to specify the path to the
contract.
We also need to pass the compiler flags, because in some cases we use
`debug` profile, and in others we use `release`.
```sway
const FUEL_COIN_CONTRACT_ID = 0x1a88d0982d216958d18378b6784614b75868a542dc05f8cc85cf3da44268c76c; // AUTO-CONTRACT-ID ../../test_contracts/test_fuel_coin_contract --release
```
In the example above, the path and flags are appended in the bash
script. I failed trying to inject commands, so I think the append is
safe.
I can remove this from the PR, if we find that this is not the solution
we want at the moment.
## 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
Removes local snapshot we were using to fund our accounts as it is now
done by default as of https://github.com/FuelLabs/fuel-core/pull/1894.
By default `--default-signer` is signing it with the account funded by
fuel-core out of the box.
## 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
It seems like we accidentally depend on released version of std in
forc-client deployment cli tests (more specifically the test folder
https://github.com/FuelLabs/sway/tree/master/forc-plugins/forc-client/tests).
This PR fixes it to point local version of std so that release PRs such
as #5452 won't get blocked.
## 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>
