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.
closes#3107
For the motivation for this PR, refer to the issue linked above.
This PR extracts all `tracing` related util functions from `forc-util`
and puts them into a dedicated `forc-tracing` crate. There is a minor
code change
[here](https://github.com/FuelLabs/sway/pull/3108/files#diff-fb650e8292a5d6bc84d8a261393ff2cabe324b5162c40ee5cf23af57ff4dcf58R161-R164)
because it is the only place that `forc-explore` uses `forc-util` (so we
can eliminate the dependency entirely), but other than that this PR is
mostly just moving code around and updating deps as required for crates
dependent on the moved `tracing` utils.
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
Previously, the language server was falling out of sync with the users
current workspace edits. For example, incorrect syntax highlighting can
be seen in the below image if the user creates a new line above the
function. The syntax then takes on the previous highlighting and all
other attributes like definition locations, warnings/error locations
etc..
<img width="700" alt="Screen Shot 2022-10-12 at 12 39 47 pm"
src="https://user-images.githubusercontent.com/1289413/195230126-9942e54a-5f61-4a3f-9efa-cf1d21653615.png">
This was happening because we load the project from disk and then get
ASTs to work with from the compiler from these files. As the users
workspace does not match the files saved on disk, then incorrect `Span`s
are in the AST. To get around this, we are cloning the users workspace
into a temporary directory on initialization of the server. On each
keystroke or edit, we update the temp files and save to disk so that we
can get an accurate AST back from the compiler for the language server
to work with. The temp directory is synchronized with the users
workspace on each did_save event.
Finally, we spawn a tokio thread and use the `notify` crate to look for
changes to the projects `Forc.toml` file. We then convert any
dependencies that have a relative path to an absolute path.
closes#2847
I've added error handling now as #2968 was merged before this one was
approved.
This PR is a WIP that aims to address the first 3 steps in #1833.
This is in anticipation of using `forc test` to support unit testing
(rather than Rust integration testing) #1832.
The `forc test` command remains for now, but outputs a message
explaining that the command is now reserved for unit testing and links
to the issues above.
## TODO
- [x] Create a new `sway-test-rs` repo or similar that can be used as a
`cargo generate` template.
- [x] Update Rust integration testing docs in the Sway book to describe
how to use the `cargo generate` command to easily add Sway integration
testing to an existing Rust project.
## Follow-up
- Create a `forc-test-rs` crate that re-exports and extends `fuels` with
useful `forc` functionality for integration testing (e.g. re-exporting
`forc_pkg::build` to ensure sway code is built and available under
`out/` at the start of testing).
Closes https://github.com/FuelLabs/sway/issues/2375https://github.com/FuelLabs/sway/issues/2362
Related https://github.com/FuelLabs/sway/pull/2798
1. adds a global `--log-level` option.
1. changes "forc completions --shell" short form from "-s" to "-S"
because "-s" is now globally the short form of "--silent"
1. similarly, changes "forc addr2line --search-dir" short from from "-s"
to "-S"
1. adds a global `--silent` option to all forc commands and renames the
old silent mode to "terse mode".
What used to be called silent mode was not really silent; it would still
output 1 line if there were warnings or errors during the build (for
example, during CI runs).
There is still a need for a non-global option for terse mode because the
test harness runs the build commands directly (without the CLI), so
there's no way to pass the global options into the command (for example,
`forc::test::forc_check::check` which takes a `forc::cli::CheckCommand`
argument).
I can't simply set the log level to "ERROR" for the test harness
(effectively like a terse mode) because it would be applied to all tests
running in that thread, and some of the tests depend on the INFO output
to stdout to determine if the test passed. To have separate log levels
for `ir_generation` and `e2e_vm_tests`, we'd have to separate those into
separate build steps.
Closes https://github.com/FuelLabs/sway/issues/2305
Adds the `--verbose` flag to all forc commands and makes it so
`tracing::debug` logs shows when `-v` or `--verbose` is used, and
`tracing::trace` logs show when `-vv` is used.
If both `RUST_LOG` and the verbose flag are set, the verbose flag takes
precedence.
Tested with permutations of:
```
cargo run -p forc -- clean --verbose
cargo run -p forc -- init -vv
```
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
Co-authored-by: Kaya Gökalp <kayagokalp@sabanciuniv.edu>
