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)
```
closes#3824.
With this PR, different tests are emitting logs separately as pointed
out by @mitchmindtree in #3808.
(Github code block indentations are showing up weird)
## Before this PR
```console
fuel/test_projects/deploy [⏱ 4s]
❯ mforc test --logs
Compiled library "core".
Compiled library "std".
Compiled library "deploy".
Bytecode size is 52 bytes.
Running 2 tests
[{"Log":{"id":"0000000000000000000000000000000000000000000000000000000000000000","is":10344,"pc":10368,"ra":1,"rb":0,"rc":0,"rd":0}}]
[{"Log":{"id":"0000000000000000000000000000000000000000000000000000000000000000","is":10344,"pc":10380,"ra":2,"rb":1,"rc":0,"rd":0}}]
test my_test ... ok (393.833µs)
test my_test2 ... ok (371.833µs)
Result: OK. 2 passed. 0 failed. Finished in 765.666µs.
```
## After this PR
```console
fuel/test_projects/deploy [⏱ 4s]
❯ mforc test --logs
Compiled library "core".
Compiled library "std".
Compiled library "deploy".
Bytecode size is 52 bytes.
Running 2 tests
test my_test ... ok (608.041µs)
[{"Log":{"id":"0000000000000000000000000000000000000000000000000000000000000000","is":10344,"pc":10368,"ra":1,"rb":0,"rc":0,"rd":0}}]
test my_test2 ... ok (360.041µs)
[{"Log":{"id":"0000000000000000000000000000000000000000000000000000000000000000","is":10344,"pc":10380,"ra":2,"rb":1,"rc":0,"rd":0}}]
Result: OK. 2 passed. 0 failed. Finished in 968.082µs.
```
closes#3807.
- Moved `Log` and `LogData` formatting code from `forc-client` to
`forc-util` as `forc-test` needs it too.
- Added `--logs` and `--pretty-print` flags to `forc-test`
This PR, refactor the `BuildPlan` generation a little to be able to
re-use some of the parts from other crates that requires to create
`BuildPlan` from build opts.
On top of that this PR also introduces a way to inject list of items
into the namespace of any member of the workspace.
This is done to unblock #3729closes#3763.
This bootstraps the EVM backend via the following:
- [x] Add build target support. This is implemented as a `--build-target
/ --target` CLI flag in Forc.
- [x] Allow for multiple asm builders The existing architecture was
refactored to be trait-based, and the code was split into two
directories, for `fuel` and `evm` backends.
- [x] Add minimal EVM assembly output.
- [x] Add `evm` target testing support.
- [x] Implement EVM smart contract memory loader
- [x] Implement basic Solidity ABI generation
The goal of this PR is to reduce code bloat. So it does a number of
things, although there are _no functional changes_.
1. Change the canonical code name from "declaration engine" to "decl
engine", including renaming `DeclarationEngine` to `DeclEngine`,
`DeclarationId` to `DeclId`, and `DeclarationWrapper` to `DeclWrapper`.
"`Declaration`" is a lot of syllables to say all the time haha 😅
2. Rename the `DeclEngine::look_up_decl_id` method to `DeclEngine::get`
and rename the `DeclEngine::replace_decl_id` method to
`DeclEngine::replace`.
3. Rename the `DeclEngine::insert` method to
`DeclEngine::insert_wrapper`.
4. Add a new `DeclEngine::insert` method with type param `T:
Into<DeclWrapper>` and add traits for `From<DeclWrapper>` for different
declarations. Replace and remove the dedicated "`insert`" methods with
the generic `DeclEngine::insert` method.
Co-authored-by: emilyaherbert <emily.herbert@fuel.sh>
closes#3262.
# About this PR
For unit tests in contracts, we are now deploying the contract before
executing the tests so that we can support calling into contract ABI.
With this PR testing a contract looks like:
1. Compile the contract with tests
2. Compile the contract without the tests
3. Deploy the contract (the one that we compiled without the tests)
4. Run each test as a script
Currently there is no way to obtain the contract id without deploying
the contract (related #3444) and automatic `CONTRACT_ID` injection is
not available as we cannot inject it until we solve #3622.
~I am planning to tackle #3622 and add the documentation after that as
this is not directly usable by our users until we have `CONTRACT_ID`
injection or #3444.~
I changed my mind and decided to print the contract id for now so that
this will be useable and because of that I will be adding the
documentation with this PR.
For now it the testing flow will be rough as users will need to first
run `forc test` and get the contract id and manually edit their tests
while setting up the tests (writing the `abi` casts). I will add some
explanation of the process and point to #3673 since it will make the
testing flow seamless.
## TODO
- [x] Add tests
- [x] Add documentation
This PR removes the global `DeclarationEngine` in favor of keeping a
local copy in the `TypeCheckContext`.
This PR is pretty big... there aren't any additional things added other
than what I """ had to add """ in order to complete this task. At a high
level:
- This PR introduces the `Engines` struct, which has two fields
`type_engine: &TypeEngine` and `declaration_engine: &DeclarationEngine`.
- For most/many of the traits introduced in #3353, this PR changes these
traits to take a `Engines` instead of a `&TypeEngine`
Closes#2063
Co-authored-by: emilyaherbert <emily.herbert@fuel.sh>
closes#3358.
## Summary
This PR adds workspace support to `forc-test`. Executing `forc test` in
a workspace runs all tests coming from the members of the workspace and
outputs them formatted separately. An example of the output can be seen
below. I also added workspace unit test support to testing suite and
added a `should_pass/unit_tests/` test with a workspace.
<img width="419" alt="image"
src="https://user-images.githubusercontent.com/20915464/206710608-b65fd509-6131-4ab0-8393-27bc220b220d.png">
## Summary
This PR adds `#[test(should_revert)]` tests to forc-test, enabling users
to write reverting cases in their unit tests.
Example:
```rust
script;
fn main() {}
fn my_func() {}
#[test(should_revert)]
fn my_test_func() {
my_func();
revert(0)
}
```
## Implementation Details
Since #3509 is merged, this PR only adds the required section to
`forc-test` so that it can detect if the given entry point's
corresponding function declarations has `#[test(should_revert)]`
attribute. If that is the case the passing condition is selected as
`TestPassCondition::ShouldRevert` otherwise it defaults to
`TestPassCondition::ShouldNotRevert`.
I also added a safety check for erroneous declarations such as
`#[test(foo)]`. Since we just have `should revert` tests right now, I am
checking if there is an argument provided with the test attirbute. If
there is none, test is considered to be
`TestPassCondition::ShouldNotRevert`, tl-dr; default is non reverting
tests. If there is an argument and it is `should_revert`, test is
considered to be `TestPassCondition::ShouldRevert` and finally if there
is an argument but it is not `should_revert` an error is produced.
A simple should revert test with `revert(0)` added to unit tests as
well.
OK, this should be good to go!
## Highlights
- Adds support for multiple entry points to IR. Adds a tests for
serializing entry functions to/from IR.
- Enables ASM generation for libraries (to support test function entry
points).
- Track entry points through ASM generation so we can return entry point
metadata as a part of the compilation result. This doesn't affect ASM
generation, but allows tools using `sway-core` as a library to work with
different entry points.
- Updated E2E test harness with a new test category "UnitTestsPass".
- Added E2E tests with multiple unit tests for each type of Sway program
(library, script, predicate, contract).
- Gets `forc test` working with pretty output!
Here's the output from the new `lib_multi_test`:
## Test running implementation
Currently, it seems like there's no publicly accessible approach to
execute a script directly from a custom entry point. As a result, for
each test, we patch the bytecode with a `JI` instruction that jumps from
after the data section setup to the test's entry point. This is a bit
hairy, but works for now!
As a follow-up, we may want to consider adding support upstream in
`fuel-vm` for executing scripts directly from a given entry point. Even
if this was only exposed from the interpreter API, this would make the
`forc-test` implementation quite a bit cleaner and avoid the need to
patch the bytecode.
Alternatively, when building projects we could return more metadata
along with the compiled output (whether in memory or bytecode header) to
indicate how to work with different entry points in a more reliable
manner (rather than the magic const offset currently used in
`forc-test`).
# TODO
- [x] Add `include_tests` flag to `BuildConfig`, allowing `forc` to
trigger compilation of test functions.
- [x] Include `#[test]` fns as entry points within dead code analysis.
- [x] IR and ASM generation for test entry points.
- [x] Add `forc build --tests`.
- [x] Add `forc test`.
- [x] Always include test fns in `TyProgram` (for DCA), but omit from IR
if not building tests.
- [x] Work out how to iterate over different entry points during `forc
test`.
- [x] Only generate tests for top-level "members" (not all
dependencies).
### Follow-up:
- #3260
- #3261
- #3262
- #3263
- #3264
- #3265
- #3266
- #3267
- #3268Closes#1832.
