## 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.
Moves following `Cargo.toml` fields to workspace `Cargo.toml` so we
don't have to keep repeating ourselves:
- edition
- authors
- homepage
- license
- repository
## Description
Closes#3681
I meant to tackle #3077 first, but tackling #3681 first cleans up a lot
of the code needed to make #3077 easier.
This PR is mostly cleanup:
- Completely removes usage of `ConfigTimeConstant` everywhere (in
forc-pkg, sway-core, sway-type)
- **(BREAKING)** Completely removes support for `[constants]` table in
the manifest, which was using the `ConfigTimeConstant` struct. This
change is breaking for app devs ([open
issue](https://github.com/FuelLabs/sway-applications/issues/375)) and
from a [quick
search](https://github.com/FuelLabs/sway-applications/search?l=TOML&q=%5Bconstants%5D)
on our sway-applications repo, there's a number of manifests still using
the old version of configuration time constants.
Consequentially, the above change also allowed us to cut down on other
constructs like `ConstInjectMap` within forc-pkg, since the only thing
we need to inject now are const CONTRACT_IDs - this cuts down quite a
bit of now-redundant code.
- As a result of the removal of `ConfigTimeConstant`, a few tests using
that feature were also deleted.
- Also updated the `configurable` example to be known as
`configurable_constants` instead of `config_time_constant`.
**This PR does not:**
- Fix the manual creation of `CONTRACT_ID` const. To create the const,
we still undergo manual parsing and type-checking and finally inserting
into a `SymbolMap` manually. This will be handled in a separate PR to
tackle #3077
Other than removal of a lot of code to do with CTC, the main change here
that allows contract dependencies to still work here is instead of
relying on the `ConstInjectMap` which we used to inject both constants
and contract dependencies, there is now only a single contract ID value
that we require (this is abstracted as `ContractIdConst`) to inject into
the contract for tests.
## 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.
## Description
closes#3571.
closes#4162.
This PR adds the ability of calling multiple contracts from sway unit
tests if they are added as `[contract-dependencies]`. This is limited
with contracts currently but I will be having a follow-up which builds
upon this to introduce this support to scripts as well.
As these contracts are already declared under `[contract-dependencies]`
their contract ids are injected into their namespace by `forc-pkg`. A
bug related to this step is fixed in #4159.
<img width="787" alt="image"
src="https://user-images.githubusercontent.com/20915464/224345002-92dc2bcb-823d-4971-9041-31111cf85e77.png">
### Follow-ups
- #4161
- ~#4162~
## 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: Kaya Gokalp <kayagokalp@fuel.sh>
## Description
closes#3988.
We added these span based filters as it was possible to declare
duplicate dependencies in a transitive manner and this was causing tests
to be duplicated. After the recent re-work of our module structure, it
is not possible to declare such packages anymore, so we do not need
these filters in-place.
## 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
This PR applies new clippy suggestions from a new clippy update.
## 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: emilyaherbert <emily.herbert@fuel.sh>
## Description
closes#4155.
unblocks #4156.
Since we are using the build profile derived from build flags of forc
for nodes in the dependency graph, contract dependencies can end-up
getting compiled with tests (we are fine if we compile with `forc build`
but this issue surfaces once we use `forc build --tests`). This is not
something we want because of two reasons:
1. In terms of `forc-pkg`: We shouldn’t allow this as inserted contract
id and deployed contract id should be the same for the feature to work
all the time. (This is the case if you run forc build today but if you
run forc build --tests the inserted contract ids are essentially wrong,
if you have some tests in those packages)
2. In terms of `forc-test`: The contract deployment’s are done without
the tests so their contract ids are calculated without the tests, since
forc-pkg inserts the contract id calculated with tests included. The
actual contract id in the interpreter instance and injected contract id
is different. This means calls using the following abi declaration is
failing: `let abi = abi(MyContractABIinContractDependency,
contract_dependency::CONTRACT_ID)` . Basically we cannot use contract id
namespace injection feature with the unit tests.
`forc-test` related problems are not apparent yet since multi contract
calls are not enabled (they will be with #4156).
## 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.
- [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).
- [ ] I have requested a review from the relevant team or maintainers.
## Description
closes#2411.
This PR adds used gas information to the output of `forc test`. An
example run can be seen below:
<img width="534" alt="Screen Shot 2023-02-24 at 4 47 29 PM"
src="https://user-images.githubusercontent.com/20915464/221198624-a3bdb264-2182-4b9d-9497-7d8cfe84132b.png">
This is done automatically without any flags. I felt like this should be
the default way but open to suggestions if you feel like it should be
behind a flag like `--gas-usage`.
Also by accessing `TestResult` structs new used gas field, we can add
this information into vscode plugin just like #513. We do not have a
line by line gas cast information just yet but we could show the whole
test's used gas info next to the run button or something in vscode.
Thoughts @JoshuaBatty @sdankel
Please let me know if anyone has any requests around the flag and the
way we are printing the used gas. Maybe @nfurfaro could have some ideas
as the prime user of `forc-test` 😄
## 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.
Closes#3190
## 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.
- [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#3952.
This PR adds:
1. Revert code for failing tests
2. Known error signals for failing tests
3. Logs for failing tests
## 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.
## Description
closes#4034.
This is a hot-fix until #3947 is fixed. This PR adds a filter to test
count to filter out duplicate test entries caused by duplicate dep
declarations.
related to #3988.
## 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.
- [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#3329.
This PR filters unrelevant member nodes for `forc-client` operations in
workspaces. `forc deploy` only builds contracts and `forc run` only
builds scripts. This is done by adding a filtering capability to
`forc-pkg`.
## 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
Bump to `v0.35.0` for a new release.
## 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 addresses couple of left over comments from previous PRs and
introduces a general clean-up to the `forc-test`. Since lots of new
stuff added rapidly to the codebase some of the comments were left over.
Especially from
https://github.com/FuelLabs/sway/pull/3672#pullrequestreview-1239935588
## 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 adds a step to execution of unit tests so that duplicate unit
tests are omitted. Duplicate tests are generated from dependencies
declared with `dep` keyword in a duplicate manner (see #3947). Until
that is fixed this PR de-duplicates sway unit tests based on their
`span`. Once the fix for #3947 is ready we can remove the changes from
this PR. This is also commented in the code.
closes#3813.
## 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.
closes#3673.
## About this PR
This PR adds `CONTRACT_ID` injection while building contracts with `forc
build --test`. `CONTRACT_ID` is the id of the contract without the tests
added. To find out that id, we first compile the contract without tests
enabled.
The rough outline of stuff happening here:
1. We iterate over `BuildPlan` members to find out contracts and collect
their contract id into an injection map. In this step only the contracts
are built. To determine contract id we need to compile the contract
without tests. Since we also need the bytecode of the contract without
tests, we are collecting them as we come across them while iterating
over members.
2. With the injection map build and execute all the tests, so basically
after first step we are just doing the old `forc-test` behaviour.
So basically I added a pre-processing step for contract id collection
for those members that require it (contracts).
This enables the following test structure:
```rust
let caller = abi(MyContract, CONTRACT_ID);
let result = caller.test_function {}();
assert(result == true)
```
