## 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
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 is the final step in implementing the `panic` expression and the
ABI errors, as defined in the [ABI Errors
RFC](https://github.com/FuelLabs/sway-rfcs/blob/master/rfcs/0014-abi-errors.md).
The PR generates the `errorCodes` section in the ABI, like, e.g.:
```
"errorCodes": {
"18446744069414584320": {
"pos": {
"pkg": "my_lib@1.2.3",
"file": "src/lib.rs",
"line": 42,
"column": 13
},
"logId": null,
"msg": "Error message."
},
"18446744069414584321": {
"pos": {
"pkg": "my_contract",
"file": "src/main.rs",
"line": 21,
"column": 34
},
"logId": "4933727799282657266",
"msg": null
}
}
```
If the `panic` argument is a string slice that can be const-evaluated,
the `msg` field of the corresponding error code is generated, and a log
is not emitted. The string itself is stored only within the ABI JSON,
and is not included into the generated bytecode.
Additionally, the PR:
- provides a common infrastructure for obtaining a `SourceLocation` from
a `Span`. This is currently used in the implementation of the `__dbg`
intrinsics and the `panic` expression.
- improves filtering of `forc` outputs in snapshot tests by supporting
regular expressions. The `grep` command is renamed to `regex` to avoid
confusion with piping the actual `grep` CLI command.
Partially addresses #6765.
## 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.
---------
Co-authored-by: hal3e <git@hal3e.io>
## 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>
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
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
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
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
Closes#4117
Allow multiple salt declarations in `forc deploy`, with parsing and
validation involved. The gist of it is that it collects all the salt
inputs by the user as a `Vec<String>`, parses each input as a `Salt` and
store them in a `ContractSaltMap` matching contract->salt, and later
compares them against the contract dependencies to make sure that
duplicate salts do not exist.
This throws an error if:
1) multiple salts are present (if the same salt is declared but also
found within a contract dependency),
2) if a salt is invalid,
3) if the salt input is invalid (there's a difference - the salt input
is the string `<CONTRACT>:<SALT>`, while the salt above is
`fuel_tx::Salt`, which has its own validation.
4) duplicate salts for the same contract were provided in the CLI.
Tests consist of dummy folders (not entire full package initialized by
forc) with only manifests to keep it the bare minimum required for these
tests.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [ ] I have requested a review from the relevant team or maintainers.
---------
Co-authored-by: Mohammad Fawaz <mohammadfawaz89@gmail.com>
