## Description
This PR adds 3 things:
1. Adds a benchmark for the format LSP request.
2. Calls `session.wait_for_parsing();` before computing the `code_lens`
request. This fixes the original issue reported in #4893 where run
buttons where being placed incorrectly after formatting.
3. If a file open in a code editor contains unsaved changes we write a
lock file to `.forc/lsp_locks/`. This file is removed when the file is
saved and there are no pending changes. If `forc-fmt` is run in a
terminal we check if the path has a lock file associated with it. If
unsaved changes are detected we bail from formatting with an error
message instructing the user to save changes before continuing. See
video below.
75e6fddc-adbc-4796-aeb9-985574ae8dcc
closes#4893
## Description
This PR introduces `string slices`.
The basic usage is at `test/src/ir_generation/tests/str_slice.sw`:
```sway
let a: str = "ABC";
```
Before this PR `a` would be of type `str[3]`, a string array.
Now both `string slices` and `string arrays` exist. This PR contains a
new intrinsic that converts from string literals to arrays.
```sway
let a: str = "ABC";
let b: str[3] = __to_str_array("ABC");
```
Runtime conversions can be done using
```sway
let a = "abcd";
let b: str[4] = a.try_as_str_array().unwrap();
let c = from_str_array(b);
```
string slices to string arrays can fail, so they return
`Option<str[N]>`; and because of this `try_as_str_array` lives in `std`.
The inverse, `from_str_array` only fails if `alloc` fails and lives in
`core`.
At this PR `string slices` are forbidden at `configurable`, `storage`,
`const`, and main arguments and returns. The reason for these
limitations is the internal structure of `string slices` having a `ptr`.
The optimized IR for initializing the slice is:
```
v0 = const string<3> "abc"
v1 = ptr_to_int v0 to u64, !2
v2 = get_local ptr { u64, u64 }, __anon_0, !2
v3 = const u64 0
v4 = get_elem_ptr v2, ptr u64, v3
store v1 to v4, !2
v5 = const u64 1
v6 = get_elem_ptr v2, ptr u64, v5
v7 = const u64 3
store v7 to v6, !2
v8 = get_local ptr slice, __anon_1, !2
mem_copy_bytes v8, v2, 16
```
## 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
Closes https://github.com/FuelLabs/sway/issues/5010
Now instead of a panic, the user sees this:
<img width="836" alt="image"
src="2da2e075-8a10-4ed4-8892-1c95cc42af63">
With debug logging they can see the compiler error, or they can simply
run the compiler.
## Checklist
- [x] 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.
## 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
closes#4862.
waiting for #4905 to be merged first.
With this PR, we are now pointing empty accounts to beta-4 faucet with
their address already inserted so that people can click on it and get
funded.
```console
Please provide the password of your encrypted wallet vault at "/Users/kayagokalp/.fuel/wallets/.wallet":
Error: Your wallet does not have any funds to pay for the transaction.
If you are interacting with a testnet consider using the faucet.
-> beta-4 network faucet: https://faucet-beta-4.fuel.network/?address=fuel1l6su7ldka75ntmz7vx05tfznshxjpa4ftt4p537vl2ck45a5p5tsmwjevm
If you are interacting with a local node, consider providing a chainConfig which funds your account.
```
---------
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
## Description
closes#4861.
This PR derives first account after creating a fresh wallet via
forc-deploy so that we have at least one account available for users to
chose from.
---------
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
closes#4744.
This PR adds deployment artifact serialization to forc-deploy. Basically
each deployment info is saved as a json file in the out folder. So that
users wont lose precious deployment information after closing their
terminal.
An example deployment artifact can be seen below:
```json
{
"transaction_id": "0xec27bb7a4c8a3b8af98070666cf4e6ea22ca4b9950a0862334a1830520012f5d",
"salt": "0x9e35d1d5ef5724f29e649a3465033f5397d3ebb973c40a1d76bb35c253f0dec7",
"network_endpoint": "http://127.0.0.1:4000",
"chain_id": 0,
"contract_id": "0x767eeaa7af2621e637f9785552620e175d4422b17d4cf0d76335c38808608a7b",
"deployment_size": 68,
"deployed_block_id": "0x915c6f372252be6bc54bd70df6362dae9bf750ba652bf5582d9b31c7023ca6cf"
}
```
Since serde serialization for `ContarctId` and other deployment related
client/vm primitives do not emit 0x at the beginning i had to convert
them to `String`s with 0x prefixed. I feel like we can change human readable
serialization to include 0x to all hex fields by default.
## Description
This PR deprecates `--unsigned` flag in favor of `--default-signer`. The
reasoning is the following:
The reason `forc-deploy` was offering `--unsigned` flag was enabling
users to create deployment transactions agains their local node without
going through wallet funding steps, an ease of development & testing.
There are some accounts funded by fuel-core by default, we can still
offer the same seamless deployment to local node by signing them with
one of these default accounts.
This pull request is an upgrade to a `fuel-core 0.20.1` release.
The biggest changes coming from this new release is a rework of how
AssetId is structured to support [granular asset
minting](https://github.com/FuelLabs/fuel-specs/pull/491). This means a
contract can mint and burn multiple AssetId's, and the ContractId !=
AssetId.
---------
Co-authored-by: bitzoic <bitzoic.eth@gmail.com>
Co-authored-by: Cameron Carstens <54727135+bitzoic@users.noreply.github.com>
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
Co-authored-by: Brandon Kite <brandonkite92@gmail.com>
Co-authored-by: Sophie <sophiedankel@gmail.com>
## Description
closes#4757.
closes#4756.
This PR adds balance query capabilities to forc-deploy so that users can
select the desired account to use before signing their transaction.
Current output looks like:
```console
Please provide the password of your encrypted wallet vault at "/Users/kayagokalp/.fuel/wallets/.wallet":
Account 0 -- fuel1x6pc0g9gwp2c2hzhejlw7l4guqd99732zt2wd68j2ukrdu59kv9qqz9h3k:
Asset ID Amount
0000000000000000000000000000000000000000000000000000000000000000 4294967295
Please provide the index of account to use for signing:0
Do you accept to sign this transaction with fuel1x6pc0g9gwp2c2hzhejlw7l4guqd99732zt2wd68j2ukrdu59kv9qqz9h3k? [y/N]: y
Contract deploy_test_integration Deployed!
Network: http://127.0.0.1:4000
Contract ID: 0x73ea64a310b6fc2c9e6674a49f5515f01950d97cc845cb4149ececea6cbf4060
Deployed in block 0x45ee78fed1083c7734246cb93258dcdc865fc9bc13667b89088aeb43037
```
Also now forc-deploy throws an error for empty accounts:
```console
Please provide the password of your encrypted wallet vault at "/Users/kayagokalp/.fuel/wallets/.wallet":
Error: Your wallet does not have any funds to pay for the deployment transaction.
If you are deploying to a testnet consider using the faucet.
If you are deploying to a local node, consider providing a chainConfig which funds your account.
```
Once we integrate a nice TUI selection library the output could be more
interactive with up and down keys etc.
## Description
This PR is part of https://github.com/FuelLabs/sway/pull/4794. It
implements the `not` operator for u256 and allows values bigger than
`u64`.
To support that it implements `U256` inside `sway-types`. For now, it is
a bare minimum wrapper around `BigUint`. We may use fuel macro in the
future, which implements all necessary functions.
## 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: Anton Trunov <anton.a.trunov@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.
## Description
closes#3439.
This PR adds `--args` flag and encoding capabilities to `forc-run` so
that users can provide inputs to main function of the script they are
running.
## Description
This changes addresses the issues introduced in #4878
The `error_emitted` pattern is replaced by a scoping method on `Handler`
that collects errors within a closure and will error out if new erros
are introduced.
All instances of introducing `ErrorEmitted` as a literal value have now
been replaced by passing arround the receipt of the error emission
through the error representing values. Some types from the AST had to be
moved to `sway-types` to avoid circular dependencies introduced by this
change.
This also repairs some of the discrepancies to emitted warnings
introduced in #4878, as well as rename some of the `Handler` methods.
Fixes#4885Fixes#4886
## 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
This PR is part of https://github.com/FuelLabs/sway/pull/4794. It
implements the bare minimum to support `u256` constants across the
stack.
They are represented in sway in hex literals with `u256` suffixes. Hex
without suffix will still be `b256`, for backward compatibility until we
implement `u256` completely. Then we can decide what to do.
There are multiple places in the code that will fail if the literal does
not fit in u64. This will be fixed later in a specific PR for big u256.
Some places have temporary `unwrap()`, that will be removed later. I can
try to remove them now, if necessary.
I am leaving all documentation updates for when everything is
implemented.
## 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: Anton Trunov <anton.a.trunov@gmail.com>
## Description
Change error handling to use `Handler` instead of the macro based
`CompileResult`.
Fix#2734
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
Updates fuel-core, fuel-vm, and other fuel-* and fuels-rs dependencies
to versions corresponding to fuel-core 0.19 release.
---------
Co-authored-by: Green Baneling <XgreenX9999@gmail.com>
## Description
closes#4754.
If the default path does not contain any wallet, forc-deploy
automatically suggests creating a new one via forc-wallet:
```console
Could not find a wallet at "/Users/kayagokalp/.fuel/wallets/.wallet", would you like to create a new one? [y/N]: y
Please enter a password to encrypt this private key:
Please confirm your password:
Wallet created successfully.
```
At this step a new window opens with your mnemonic just like
forc-wallet's new flow. User pres enter:
```console
Please provide the password of your encrypted wallet vault at "/Users/kayagokalp/.fuel/wallets/.wallet":
Do you accept to sign this transaction with fuel13pudgkhq9pmsj3s2nwxmsmydqnau3lcpn5m70jrg5mrw0dlc3r8qz6pjdk? [y/N]: y
```
User is asked for their password again, to prevent this I need to cut
another release to forc-wallet which is currently blocked. So I will fix
that in a follow-up PR.
## Description
closes#4759.
Adds --target parameter to forc-deploy which can take `beta-2`, `beta-3`
or `latest`. If nothing is specified it defaults to `latest`. If
`beta-2` or `beta-3` is specified, preset values are used for node-url
and gas price so that users can deploy with a single parameter. So `forc
deploy --target beta-3` would work but since forc-deploy is not
compatible with beta-3 that feature will fail until we have a beta-4
released.
Also adds `--testnet` flag which is translated into a `--target beta-3`.
So once a beta network release is done with this additions, users will
be able to simply use
```console
forc deploy --testnet
```
to deploy to the latest test-net supported by that forc-deploy version
## 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: Joshua Batty <joshpbatty@gmail.com>
## Description
closes#4758.
This PR makes --random-salt the default behaviour of forc-deploy, if
salt information is passed, the passed salt would be used but otherwise,
random-salt would be implied by default. Also adds --default-salt for CI
so that in CI we can always create the same contract id if we want to.
Useful for reproducible deployments.
## Description
closes#4043.
Improves error message by stating the failure reason clearly if the
reason is insufficient funds. If the transaction is failing due to
insufficient funds we are outputing:
```console
Contract id: 0xa8f18533afc18453323bdf17c83750c556916ab183daacf46d7a8d3c633a40ee
Please provide the password of your encrypted wallet vault at "/Users/kayagokalp/.fuel/wallets/.wallet":
Do you accept to sign this transaction with fuel1egx2nvm4395gukm8uyh4zzxdlx3hht9ulu6n67nhwq57zs74camskx7klp [y/N]:y
Error: Deployment failed due to insufficient funds. Please be sure to have enough coins to pay for deployment transaction.
```
We will have a balance checking mechanism before signing the transaction
for test-net which would make this error only visible to manual signers
and people that are working against a local node.
## Description
closes#4743.
This PR integrates forc-wallet and forc-deploy together so that
forc-deploy can offer to sign your transactions without running a second
terminal window. Below there are some inputs and outputs after this
change.
## Description
Fixes the following warning by moving `default-features = false` to
workspace level:
```
warning: /Users/kayagokalp/fuel/dev/sway/forc-plugins/forc-client/Cargo.toml: `default-features` is ignored for fuel-core-client, since `default-features` was not specified for `workspace.dependencies.fuel-core-client`, this could become a hard error in the future
```
## Description
Closes#3926.
(edited by @kayagokalp to reflect latest status of the PR)
This PR adds IPFS support for forc-pkg. To do so, forc relies on
existing ipfs local node without embedding a node to forc itself. If
local system does not have an ipfs node running, a public gateway
(https://ipfs.io) is used as a fallback mechanism and packages are
fetched through that.
## Some Context and Future Work
For our package registry stuff to work properly we will eventually need
to host an IPFS node to make sure that our published packages are pinned
by at least one node in the network. That is the case as long as we
don't have a way to incentivize people pinning the packages they
published. What will happen is that a package will be published by a
developer and after we detect the published package our own IPFS node
will pin it to make sure it is always accessible.
Also some benchmarks are done for public gateway during development. It
looks like for initial fetch operations from public gateway spends some
time looking for the package pinned by the IPFS node simulating our
incoming fuel IPFS node which is explained above. It is manageable but
fetching from the fuel IPFS node is instant as it already got the
package pinned. We can consider falling back to our own node's gateway
api rather than a public one to smooth the process.
Finally maybe we can explore embedded ipfs node option as a follow-up,
due to the status of IPFS with Rust, it is not very obvious (maybe not
event possible atm) how to be able to be fully compatible with kubo, for
fetching/publishing our packages. But this is still an open question
worth exploring.
## Testing
### To test with a local node:
1. You can install kubo, you can follow the instructions in their
website while installing https://docs.ipfs.tech/install/command-line/
2. Run the `ipfs daemon` service with `ipfs daemon`
3. Add an ipfs source, I have a package already pinned by my IPFS node
that you can use:
```toml
[dependencies]
test_lib = { ipfs = "QmfZ3uH7dFEDkYN5RQfyu4m7L8uk8kGiLkNwzHqsrormSj" }
```
4. Run `forc build`
### To test public gateway fallback:
1. Either do this before starting `ipfs daemon` or stop your local
daemon with `ipfs shutdown`.
Add an ipfs source, I have a package already pinned by my IPFS node that
you can use:
```toml
[dependencies]
test_lib = { ipfs = "QmfZ3uH7dFEDkYN5RQfyu4m7L8uk8kGiLkNwzHqsrormSj" }
```
2. Run `forc build`
---------
Co-authored-by: kayagokalp <kaya.gokalp@fuel.sh>
## Description
closes#4667.
To be more WASM friendly and increase reuseability of `forc-util` this
PR hides fuel-tx related utilities under `fuel-tx` flag.
## Description
Closes https://github.com/FuelLabs/sway/issues/4645
This PR lets the user generate doc comments for ABI methods. Previously
it was working for functions and function implementations of ABI/trait,
but not on the ABI/trait definition itself.
Since the output is exactly the same for FunctionDecl to TraitFn, I
wanted to do this in a way where they could share the code. I ended up
writing a trait called `FunctionSignature` that both types implement
that exposes `parameters()` and `return_type()`. This allows me to use
the same code for code actions and I suspect it will come in handy in
the future.
One problem was that `FunctionDecl`'s return_type was `TypeArgument`
while `TraitFn` had its return type as `TypeId` with an additional
`return_type_span` field. I changed it so that `TraitFn`'s return_type
is now `TypeArgument` and removed `return_type_span`.
I also needed to add a `span` field to `TraitFn` since previously its
`span()` was returning only the span of the function name, not the whole
function. From what I could see, this doesn't impact the spans of any
existing errors.
### Testing
I added an integration test to the LSP for this scenario.
### Example
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [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
Inspired by #4588
## 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
Waiting for:
- #4525.
@Dhaiwat10 was waiting for a release with the linked PR merged.
@IGI-111 I had the PR ready, leaving it up to you when to merge & cut
the release. Made this a major bump as we had a breaking change merged
(#4574).
## Checklist
- [ ] I have linked to any relevant issues.
- [ ] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [ ] I have requested a review from the relevant team or maintainers.
Co-authored-by: IGI-111 <igi-111@protonmail.com>
The PR fixes breakings changes from the `fuel-core 0.18.1` and `fuels-rs
0.41`.
- The `__smo` is reworked and doesn't require an output index because we
removed the `Output::Message` variant.
- Replaced the old deploy API with a new one, `Contract::deploy` ->
`Contract::load_from().deploy()`.
- The signing of the transaction and predicate id calculation requires
`ChainId` now. It breaks the API in some places. In tests, I used the
default chain id, but from the `forc` perspective we need to add the
ability to specify it.
- `fuels-signers` was renamed into `fuels-accounts`.
- We reworked `fuel_tx::Input` and now each variant of the enum has a
named type.
- Replaced all unsafe code from `fuel-crypto` with safe analog.
- On the `fuel-tx`/`fuel-core` side now, there is a difference in
whether the message contains data. If data is empty, it is `MessageCoin`
that acts like a `Coin`(has the same rules during execution). If the
data field is not empty, then it is a retryable message(or
`MessageData`). Messages like this can't be used to pay a transaction
fee, and if the execution fails, the message is not consumed(you can use
it again in the next transactions). More about them you can read in
https://github.com/FuelLabs/fuel-core/issues/946. Also, the API changed
for resources and not it is `Coins` again. Because of that, some tests
now require messages with empty data to be able to spend them.
- Removed redundant usage of `MessageId` and corresponding fields. Now
the identifier of the message is a `Nonce`.
- Removed `Output::Message`. Now you don't need to specify it in the
outputs. Because of that `SMO` opcode doesn't require a message output
index anymore.
- We unified block height(in some places it was `u32` in some `u64`) by
introducing the `BlockHeight` type.
- The `nonce` in the `Message` is a `Bytes32` now instead of
`u64`(affected `input_message_nonce` GTF).
- Reworked the handling of the `Intrinsic::Smo`. Previously `fuel-vm`
expected `smo(r1: receipt_and_message_ptr, r2: size_of_the_message, r3:
output_index, r4: amount)` but we updated that to be `smo(r1:
receipt_ptr, r2: message_ptr, r3: size_of_the_message, r4: amount)` -
according to the specification.
- Removed `input_message_msg_id` GTF.
- Now tokens should be transferred to the contract first, and after you
can transfer them via `SMO` or another transfer. So in some tests first
we need to transfer money to the contract first.
- The `fuels-rs` now generates a separate structure for encoder
`{Contract_name}Encoder`.
This PR is based on the https://github.com/FuelLabs/fuels-rs/pull/950
and causes cycle dependencies. The `fuels-rs` should be released first
and after we can apply it.
---------
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
Co-authored-by: iqdecay <victor@berasconsulting.com>
Co-authored-by: Kaya Gökalp <kaya.gokalp@fuel.sh>
## Description
Adds an initial benchmarking setup to CI, where a collection of
libraries from https://github.com/FuelLabs/sway-libs are compiled,
performance metrics generated and later pushed into a new repo:
https://github.com/FuelLabs/sway-performance-data
Closes https://github.com/FuelLabs/sway/issues/318.
## 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
Set experimental module privacy rules as the default and remove the
experimental flag.
Closes#4506
## 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
As title says, this refactor existing code to pass the engines type to
more places, and adds a new query engine while at it.
The query engine in this form still does not do anything at all, but
will be populated next with the necessary bits for its purpose.
## 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
Generates the documentation for dependencies & small improvements to the
API.
These changes **DO NOT** create links between dependency docs and the main docs, but generates the dependency docs and ensures there are no conflicts when generating these docs.
What's new so far:
- [x] Programs get their own folders, just like `cargo doc`
- [x] Generates documentation for dependencies by default: Closes#4533
- [x] Fixes possible conflict with `assets` folder: Closes#4545
- [x] Removes old docs before generating new ones: Closes#4544
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
---------
Co-authored-by: Chris O'Brien <eureka@noctua.attlocal.net>
