## 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.
This is a small refactor of the `forc-client` crate in anticipation of
including the new `forc submit` command (see #3885) as a new binary
output for the crate.
This PR inverts the forc-client module hierarchy to follow `forc`'s
layout a little more closely.
It also refactors the command types in order to better share sets of
clap arguments between different commands with the aim of reducing code
duplication and providing a more uniform experience across all official
forc commands/plugins. This will be improved further once the `forc
submit` command is included, allowing us to share some of the networking
arguments too.
---------
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
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#3622.
closes#3586.
unblocks #3673.
## About this PR
After parsing, I added a check to remove tests from `AstTree` if tests
are not enabled. Since all the other checks are done after this
exclusion of tests, this PR also prevents warnings and errors coming
from test functions to be emitted while using `forc build`. They are
still visible with `forc test` as they should be.
Previous to this PR, `forc_pkg::check()` would only return the
`ParseProgram` and `TyProgram` AST's. In the language server, we now
also need access to the initial lexing stage produced by `sway_parse` in
order to get access to the sway keyword tokens.
This PR now returns the lexing stage of a program along with the parsed
and typed stages.
closes#3524
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">
This is a minimal start at documenting the Sway unit testing feature
provided via `forc test`.
We should continue to extend this as we land new features like contract
calling, dev-dependencies, `#[test(should_revert)]`, etc.
We weren't collecting tokens imported by default with the new std lib
prelude. This PR now collects these tokens so we can do things like show
documentation for imported types on hover requests.
closes#3208
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.
Bumping everything all at once due to transitive dependencies that have
to match.
Only to `fuel-core 0.11.2` for now and all the other dependencies it
uses.
To bump to `fuel-core 0.12.0`, we need a new release of `fuels` that
uses `fuel-core 0.12.0` (pending
https://github.com/FuelLabs/fuels-rs/pull/656).
This is in anticipation of introducing a new `forc-test` library crate
that will contain the logic for building and executing tests. It will
expose a similar `TestOpts` type that shares some of these parts, but
not all.
Also splits up the forc `BuildCommand` for easier sharing between sets
of clap arguments (using the `clap` `flatten` attribute) that require
building a project (e.g. build, test).
Also adds two missing args to the `RunCommand` (`release` and
`build-profile`).
Co-authored-by: Mohammad Fawaz <mohammadfawaz89@gmail.com>
This strips out a couple commits from #2985 and aims to land them
independently!
Specifically, this enables calling `forc build --tests` which will (once
#2985 lands) build the current project along with all its tests.
Eventually we'll also want `forc check --tests` and `forc test` itself,
but landing this command early is particularly useful for testing the
new in-progress unit testing feature.
This PR also removes the old `AsmOrLib` and `BytecodeOrLib` types in
favour of new `CompiledAsm` and `CompiledBytecode` types. This is in
preparation for #2985 in which libraries will begin to generate bytecode
when tests are enabled.
