## Description
A new `Diagnostic` type is introduced for detail description of compile
errors and warnings. The change is backward compatible. The existing
`CompileWarning`s and `CompileError`s will continue render as they had
before.
The `Diagnostic` is formed out of a:
- _Level_: Error or Warning.
- _Code_: Unique error or warning code. Placeholder for future. Not used
at the moment.
- _Reason_: Short description of the diagnostic, not related to a
specific error/warning. Answers the question "Why is this an
error/warning?" E.g., Because - "Constants cannot be shadowed".
- _Issue_: Short description of the concrete case that the compiler has
found. E.g., "Variable "X" shadows imported constant with the same name"
- _Hints_: Detailed description of the diagnostic placed in the source
code.
- _Help_: Additional friendly information that helps understanding and
solving the issue, but which is not related to a place in code.
The `Diagnostic`s are defined imperatively in code right now, pretty
much the sam way we do `CompilWarning`s at the moment. Development of a
proc-macro that should make de definitions declarative is out of scope
of #21.
## Known Limitations
The `annotate-snippets` library has a bug and a missing functionality
for which I opened issues:
- Wrong display of line numbers when using folding of lines of code.
This issue is fixed but there is no patch release provided:
https://github.com/rust-lang/annotate-snippets-rs/issues/52#issuecomment-1657829040
- No possibility to remove the "note:" prefix as shown on the image
above: https://github.com/rust-lang/annotate-snippets-rs/issues/59
These two issues are not blocking. Proposal is to wait for the official
support in the library, or contribute or in the worst case make a
workaround in our code.
## Demo (Before and After)
### Errors
### Warnings
Closes#21
## 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).
- [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).
- [x] I have requested a review from the relevant team or maintainers.
## Description
closes#4667.
To be more WASM friendly and increase reuseability of `forc-util` this
PR hides fuel-tx related utilities under `fuel-tx` flag.
## 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>
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
closes#4462.
With this PR we exit from `forc test` with 101 exit status, if there are
failing unit tests. If `forc test` execution itself fails we exit with
1. This is useful especially in CIs as the return status can be checked
to better understand what is happening.
## 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).
- [ ] I have requested a review from the relevant team or maintainers.
---------
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
## Description
closes#4461.
We introduced `ForcResult` in #4455. While implementing it I took a look
at the cargo's design and saw that they also have `CargoCliResult` which
did not make a lot of sense then but it looks like without that piece we
cannot format the error nicely because of rust's orphan rule. This PR
introduces `ForcCliResult` which enables us to return nice and clean
errors.
## Description
closes#4420.
This PR introduces `ForcResult` and `ForcError` which enables us to
return with custom exit code via propagating the desired exit code
alongside the error message. Using `ForcResult` we can exit with
different return code for different cases. Cargo uses similar approach
for similar purposes.
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#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
We now print with the following format *prior* to compiling a package:
```
Compiling <ty> <name> (<src>)
```
Rather than only printing `Compiled` after compilation is complete.
Closes#3780.
This also aims to improve the formatting of the output a little by using
ansi_term styling to distinguish between action, program kind, package
name and source more clearly.
The fetching, adding and removing actions have had their formatting
updated to match. E.g.
## 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#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#4027
This is a fix for the formatter being called to format multiple times.
This implements the suggested changes described in the issue, and
refactors some of the code:
- `format_file()` is now renamed to `write_file_formatted()`, since all
it does is write to a file.
- Extract logic of formatting a single file into `format_file()`. This
means its reusable at 3 levels: formatting a single file, formatting a
package and formatting a workspace.
- Handles formatting by workspace vs package - formatting a workspace is
handled slightly differently. Formatting a package has no changes - it
still works the same. However, for workspaces, we want to format all
files at the root, then find for each subdirectories (inclusively), all
the nested directories with a manifest inside. If it exists, we are
interested in formatting it. If the subdirectory happens to have a
`swayfmt.toml` inside it, we will prioritize that configuration file.
Generally, we should prefer member config > workspace config > default.
This nuance is [explained in a
comment](https://github.com/FuelLabs/sway/pull/4038/files#diff-bf9b5d7023fff817f83ae31bd01e66d2788178a0705a2c638ce79d7990cc374aR190-R193).
- Extract logic of formatting a manifest into `format_manifest()`
It's faster by quite a bit, with some good ol' primitive testing:
new (fmt.sh):
```
for i in `seq 1 13`; do
./forc-fmt --path AMM
done
```
The above `forc-fmt` is built on `--release` and I moved it to the sway
apps repo for testing. Looped it 13 times because that's the no. of
projects in sway-applications.
old (fmt-old.sh):
```
for i in `seq 1 13`; do
forc fmt --path AMM
done
```
This one is just the current formatter.
## 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).
- [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.
- [ ] 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: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
Co-authored-by: Kaya Gökalp <kaya.gokalp@fuel.sh>
## 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.
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`
