This PR adds support to express line number mapping from assembly to
source using DWARF object files. Since there are offset details that are
specific to the Fuel ISA, I'm using the existing `SourceMap` that's
already being built, rather than generating directly from the
instructions.
An important point to note is that DWARF uses line-col to express
positions rather than an absolute offset-from-start format. To avoid
computing line-col from absolute positions (which requires re-reading
the source files), I'm changing the source position format everywhere to
line-col. This also simplifies our code at many places (for example, in
`forc-debug`). The only exception is the `addr2line` tool, where the use
of absolute positions is in a function that seemed quite complex to me
to attempt changes. So I have, temporarily, added code to compute
absolute positions from line-col information and then reuse the existing
functions. This is inefficient, but I think that's _okay_ since it's a
standalone tool and the whole thing runs just once for every command
invocation.
The DWARF information is written to a file specified by the `-g` flag
and can be verified using `llvm-dwarfdump --debug-line ./test.obj`. If
the argument to the `-g` flag is a filename that ends with `.json`, then
the existing JSON format is written out, otherwise it's a DWARF object
in an ELF container.
---------
Co-authored-by: Joao Matos <joao@tritao.eu>
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
## Description
Related https://github.com/FuelLabs/sway-vscode-plugin/pull/166
Adds a [DAP](https://microsoft.github.io/debug-adapter-protocol//)
server as a new forc plugin, `forc-debug`. This enables a UI debugging
experience in IDEs such as VSCode.
For now, only debugging forc tests is supported. Users can:
- set breakpoints inside of forc tests
- step through the test, one VM instruction at a time, or continue to
the next breakpoint
- debug through multiple tests sequentially
- see the VM register values in the IDE while debugging
- see the current VM opcode, its inputs, and/or immediate value when
when the VM is stopped
### Screenshots
24e2016c-d96c-4ef6-931f-8a4ce4f1386b
5f0fed49-b278-4074-a1a1-d37de00776f8
### Local testing
1. Install `forc-debug`
2. Copy this sample launch.json in the VSCode workspace with sway code
to debug:
```json
{
"version": "0.2.0",
"configurations": [
{
"type": "sway",
"request": "launch",
"name": "Debug Sway",
"program": "${file}"
}]
}
```
3. Follow [the
steps](https://github.com/FuelLabs/sway-vscode-plugin/blob/master/docs/testing.md)
for testing the VSCode extension
### Limitations
- Breakpoints only work inside of the project/workspace being debugged
- Stack trace support is limited
- Not every line has source maps. Once debugging, "verified" breakpoints
will show red and "unverified" (no source maps) will be greyed out.
- Watch/repl expressions are not yet supported
- Step into/out of is not supported
- If you click "step over" many times in rapid succession, the server
takes a while to catch up.
Closes https://github.com/FuelLabs/sway/issues/5394
## 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: Vaivaswatha Nagaraj <vaivaswatha.nagaraj@fuel.sh>
Co-authored-by: Vaivaswatha N <vaivaswatha@users.noreply.github.com>
Co-authored-by: IGI-111 <igi-111@protonmail.com>
Co-authored-by: João Matos <joao@tritao.eu>
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
Co-authored-by: Igor Rončević <ironcev@hotmail.com>
Co-authored-by: Sudhakar Verma <10460978+sudhackar@users.noreply.github.com>
Co-authored-by: Marcos Henrich <marcoshenrich@gmail.com>
Co-authored-by: jjcnn <38888011+jjcnn@users.noreply.github.com>
## Description
Closes https://github.com/FuelLabs/sway/issues/5607
Solves part [1] of https://github.com/FuelLabs/sway/issues/5607 by
making "release" the default build plan for forc-deploy. It can still be
overridden, i.e. for the test harness.
Other changes:
- removed the `--release` and `--error-on-warnings` options from
forc-deploy, since those aren't needed.
- refactored `BuildProfile` into its own file and added a test, since I
noticed some of the options weren't deserializing
## 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
This PR is a continuation of https://github.com/FuelLabs/sway/pull/5306.
- I am fixing some code reviews issues that were raised in the other PR;
- I am incorporating the encoding version inside the JSON ABI as:
```json
{
"configurables": [],
"encoding": "1", <- look here
"functions": [
{
"attributes": null,
"inputs": [],
"name": "main",
"output": {
"name": "",
"type": 13,
"typeArguments": null
}
}
],
```
This field is a string to allow any kind of versioning we choose.
- This PR has also improved testing and making more explicit how each
type is being encoded.
## Dependencies
- [x] https://github.com/FuelLabs/fuel-abi-types/pull/17
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
## Description
Bumps repo to 0.49.0, made this a major one after some thought as we
longer support beta-4 as tooling with this release.
Also ran `cargo update` as this is a breaking change
---------
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
This PR changes the output of `__log` to encoded values (see
https://github.com/FuelLabs/sway/issues/4769). A quick example of what
that means is
```sway
struct S {
a: u64,
b: u32,
c: u16,
d: u8,
e: Vec<u64>,
f: str,
g: u256
}
let mut e = Vec::new();
e.push(1);
e.push(2);
e.push(3);
__log(S{
a: 1,
b: 2,
c: 3,
d: 4,
e,
f: "sway",
g: u256::max()
});
```
will output
```
[0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 2, 0, 3, 4, 0, 0, 0, 0, 0, 0, 0, 3, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 3, 0, 0, 0, 0, 0, 0, 0, 4, 115, 119, 97, 121, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255]
^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^ ^^^^ ^ ^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^ ^^^ ^^^ ^^ ^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
s.a s.b s.c s.d s.e.len() s.e[0] s.e[1] s.e[2] s.f.len() s.f[0] s.f[1] s.f[2] s.f[3] s.g
```
This works in two steps:
1 - `__log(s)` is desugared into `__log(encode(s))`;
2 - call `encode`. Its impl can be found at
https://github.com/FuelLabs/sway/pull/5306/files#diff-ee5cebc963e841e8af05f3986de17dd266ee6e9b49dbe089a5eb64764f3b802eR307
It simply creates an append-only buffer and call `abi_encode` from a
special trait named `AbiEncode`.
To be encodable, a type must implement `AbiEncode`. In the example
above, `S` is auto-implemented by the compiler because all its fields
are `AbiEncode`. But we can also have custom impl like `Vec` here:
https://github.com/FuelLabs/sway/pull/5306/files#diff-b5d9688741fea479477f26ca44cd1d1ecbd2f003f3875292abb23df7fad85c58
All this is behind a compiler flag:
```
> forc build -h
Compile the current or target project
USAGE:
forc build [OPTIONS]
OPTIONS:
...
--experimental-new-encoding
Experimental flags for the "new encoding" feature
```
The same flag is available for the `e2e` tests:
```
> cargo r -p test --release -- should_pass/language/logging --verbose --experimental-new-encoding
```
## Limitations
1 - Now that __log demands a `fn` called `encode`, when something is
compiled with `implicit-std: false`, the intrinsic function `__log` does
not work out-of-box anymore. A function called `encode` must "visible"
and the worst part is that it needs to be functional to log anything.
2 - Arrays, string arrays and tuples will have limited implementations.
Currently up to five items.
## 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: Joshua Batty <joshpbatty@gmail.com>
## Description
Related https://github.com/FuelLabs/sway/issues/2350
This refactor is not intended to change any behavior. It adds
`TestExecutor` which has a handle to `vm::Interpreter`. This will be
used to access the debugger within the VM.
Also moved the "setup" related code into a new file to make the code
more organized.
## 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
co-developed with: @IGI-111 and @xgreenx
This PR adds support for transaction policies.
What was done:
- bump `fuel-vm` to `0.43.1`
- bump `fuels-rs` to `0.53.0`
- update the `std-lib` to handle new `GTF` codes and the transaction
policies
- update all test
BREAKING CHANGE:
- removed `TxParameters` in favor of `TxPolicies`
- changed `gtf` opcodes
- removed `Mint` from `forc-tx` and cli
## Checklist
- [ ] I have linked to any relevant issues.
- [ ] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
---------
Co-authored-by: green <xgreenx9999@gmail.com>
Co-authored-by: Elvis <elvisdedic@outlook.com>
Co-authored-by: IGI-111 <igi-111@protonmail.com>
Co-authored-by: xunilrj <xunilrj@hotmail.com>
Co-authored-by: Vaivaswatha Nagaraj <vaivaswatha.nagaraj@fuel.sh>
Co-authored-by: Kaya Gökalp <kaya.gokalp@fuel.sh>
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
## Description
closes#5136.
We build contract projects twice, once without tests to get contract
bytecode for forc-test's deployment step. (Since contract project's unit
tests needs to make contract calls, we need the contract deployed to
local vm instance.) And once with the tests included if the user
executes `forc test`. This is only needed for contract projects as we
only need to deploy them for testing.
Module cache addition in 255350ec50 only
takes path into account for key. But same source file with and without
tests enabled creates different AST's and thus we should also take
`include_tests` variable into account.
We were missing contract tests because we could not build them with
tests. 1st run were building them correctly without the tests and
populated the cache, only taking `Path` into account. Second time,
although we passed `include_tests = true`, (thus the resulting AST is
going to be different for the same file) rather than creating the AST
with the tests, we were using the cached version. This was causing
contract's to lose tests entries.
## Description
This implements a set of optimizations around span usage. The main idea
is we stop using paths as strings, and instead replace it using an
integer-based id, which is way less expensive for hash map comparisons.
Here are some numbers, from the slowest test we have on the suite
(`should_pass/stdlib/vec`).
**Benchmarking Results** (`master`):
**Time** (mean ± σ): 6.129 s ± 0.080 s [User: 5.755 s, System: 0.359 s]
**Range** (min … max): 6.009 s … 6.268 s 10 runs
**Benchmarking Results** (span hash optimization):
**Time** (mean ± σ): 5.345 s ± 0.161 s [User: 5.000 s, System: 0.341 s]
**Range** (min … max): 5.082 s … 5.590 s 10 runss
**Benchmarking Results** (both span hash and SourceEngine optimization):
**Time** (mean ± σ): 4.376 s ± 0.089 s [User: 4.065 s, System: 0.309 s]
**Range** (min … max): 4.255 s … 4.546 s 10 runs
## 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
closes#3268.
This PR adds filtering capability to `forc-test` based on test names. Tests are executed if their name contains the given filter phrase.
## Description
This change mainly adds checks to enforce the new module privacy rules
and supporting changes for it.
Changes include updating std and core to use
public modules, updating the parser to allow the use of the `pub mod`
syntax and adding an error type for private modules.
This change is implemented behind a `--experimental-private-modules`
experimental flag and not enabled by default.
It implements part of https://github.com/FuelLabs/sway/issues/4446, the
`pub use` syntax is yet to be 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: Joshua Batty <joshpbatty@gmail.com>
See here for context:
https://github.com/FuelLabs/sway/pull/4492#issuecomment-1520949069
This follows a re-release of 0.37.1 as 0.37.3:
https://github.com/FuelLabs/sway/releases/tag/v0.37.3
The outcome of all this is that ideally, users previously on 0.37.1 will
now pull 0.37.3 next time they run `cargo update` and will not encounter
any breakage. Those ready to update can point to 0.38.0 after this is
published.
Also runs `cargo update` in order to update deps to their latest patch
release.
---------
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
Implement https://github.com/FuelLabs/sway-rfcs/pull/23
Closes https://github.com/FuelLabs/sway/issues/3419 (technically via the
RFC)
Closes https://github.com/FuelLabs/sway/issues/3202
Closes https://github.com/FuelLabs/sway/issues/3043
Closes https://github.com/FuelLabs/sway/issues/2639
Closes https://github.com/FuelLabs/sway/issues/2465
Closes https://github.com/FuelLabs/sway/issues/4304
This is a big one but mostly removes stuff. It's hard to review but the
summary of changes below should be sufficient. Most of the changes here
are things that I just had to do to make CI pass.
- Removed the `--experimental-storage` flag and made its
[behavior](https://github.com/FuelLabs/sway/pull/4297) the default. Also
removed everything that was required for the previous storage APIs in
favour of the new ones.
- Break down the `std::storage` into multiple submodules:
- `storage_key` implements the API for `std::core::StorageKey`
- `storage_api` implements the free functions `read` (previously `get`),
`write` (previously `store`), and `clear`.
- 4 more modules for the dynamic storage types which now use the new
`StorageKey` API.
- `#[storage(write)]` now allows reading from storage as well. This is
needed because the way we pack structs in storage now requires that we
sometimes read from storage first if we were to write a portion of a
slot.
- Removed the "storage only types" checks and the corresponding tests.
- Removed the `__get_storage_key` intrinsic and the `get_storage_key` IR
instruction and all corresponding tests. Also removed the `state_index`
metadata as it is no longer required.
- Added tests and example to showcase nested storage maps and nested
storage vectors.
## 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: Joshua Batty <joshpbatty@gmail.com>
## Description
closes#4161.
This PR enables the contract call feature for scripts. We had this
feature for the contracts (introduced in #4156) but scripts were
missing.
## Description
This PR introduces `StorageHandle` to the `core` as an **experimental**
feature. `StorageHandle` is a descriptor of a location in storage
containing two fields:
1. A key pointing to a storage slot `s`.
2. An offset pointing to a particular word in `s` or in its subsequent
slots. This offset is new and is not described in the RFC. I will
rectify that shortly.
The standard library introduces helper methods `read`, `try_read`, and
`write` to `StorageHandle` that allow reading from and writing to the
location pointed to by the handle. `try_read` returns an `Option`
wrapping the data while `read` automatically internally unwraps the data
and could panic.
The summary of this change is as follows:
* New struct `core::experimental::storage::StorageHandle`
* New storage library `std::experimental::storage::*` that should
eventually replace `std::storage::*`. This new library mirrors the old
one to the extent possible and introduces the helper methods for
`StorageHandle`. Other data structures such as `StorageVec` and
`StorageBytes` will be introduced in a separate PR.
* Add an experimental flag `--experimental-storage` to `forc` that
enables all the required code in the compiler to support `StorageHandle`
as described in the https://github.com/FuelLabs/sway-rfcs/pull/23.
* Type checking phases assumes the existence of `StorageHandle` and
monomorphizes it as needed.
* Storage accesses now always return `StorageHandle` and storage
reassignment are no longer relevant.
* IR gen handles storage accesses by "filling" the key and the offset in
an aggregate representing the `StorageHandle`. The key and the offset
are statically determined based on the index of the storage variable in
the `storage` block and the field accessed, if applicable.
* Storage initializers are now handled based on the new model
* The new approach packs struct fields by default but does not pack
across storage variables. This offers the most amount of flexibility.
This is a deviation from the RFC which I will update shortly.
* To implement `StorageMap` and other dynamic storage data structures,
we now write `impl StorageHandle<StorageMap<K, V>>` instead of `impl
StorageMap<K, V>` directly. Also, note that the `get` method now returns
a `StorageHandle` instead of the actual data. To get the actual data,
`read()` or `try_read()` should be called on the resulting handle. This
is needed for multiple reasons including proper support for nested
dynamic storage types. Rust also does the same, in a way (where `get`
actually returns ` &` which happens to coerce to the real data in
certain places).
* I added various tests but they're not comprehensive. Some tests on my
list:
* Extensive tests for storage maps in structs (which now work!)
* Extensive tests for storage accesses with various types and struct
layouts
I still need to figure out how to do nested dynamic storage types with
this approach. The stuff I have in `map_in_map_access` in
`test_projects/experimental_storage/src/main.sw` is just an attempt but
not ergonomic at all of course.
## 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).
- [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.
## Description
closes#3953
This PR adds parallel test runners to improve our test execution times
by utilizing the fact that each test is actually completely separate
from each other. Also a flag `--test-threads` added to `forc-test` to
manually control number of thread used for execution.
Simple benchmarks taken from my local system with m1 max can be seen in
below: (
*Each config is executed 10 times)*
| Num Threads | Average Time |
| ----------- | ----------- |
| 1 | 1.019 ms |
| 2 | 938 ms |
| 4 | 883 ms |
As it can be seen speed-ups aren't great as this includes building as
well which is done with single thread. So I tested just building with
tests enabled on the same project (which is sway-lib-std btw) which
takes 810ms (again averaged 10 times). So after I normalize the results
above with this data
| Num Threads | Average Time |
| ----------- | ----------- |
| 1 | 209 ms |
| 2 | 128 ms |
| 4 | 73 ms |
Speed-ups are more visible with more complex tests with increased number
of tests.
