## Description
Add macro to test argument parsing rather than testing the external
command through building and spawning a separated process. This is an
improved version of #5519
## 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 makes struct fields private by default and introduces explicit
public struct fields:
```
pub struct Struct {
pub public_field: u8,
private_field: u8,
}
```
Private fields can be accessed only withing the module in which their
struct is declared.
Error messages are properly orchestrated so that no conflicting or
duplicated messages are emitted. Since the change is a breaking change,
relevant suggestion on how to fix the particular issue are given.
To avoid an abrupt breaking change, the errors are temporarily turned
into warnings. These warnings will become errors in the upcoming
versions of Sway. The demo section below demonstrate how the errors will
look like, and how a one warning equivalent looks now.
Standard library structs like `Vec` or `String`, are adapted where
needed by adding the `pub` keyword to the fields that are accessed
outside of the struct declaration module. Some of these fields should
very likely remain public, but some, like e.g., `RawBytes::ptr` or
`Vec::buf` should be private. Adjusting the standard library to properly
utilize private fields is out of scope of this PR and will be done
separately. I expect breaking changes in the STD once we start modeling
structs keeping encapsulation in mind.
In addition, the PR:
- migrates
[annotate_snippets](https://github.com/rust-lang/annotate-snippets-rs)
crate to its latest version (breaking changes)
- removes a redundant non-existing field error and orchestrates
non-existing field error with privacy errors
- replaces an invalid and misleading error when accessing fields on
storage elements that are not structs
Closes#4692.
## Known limitations
There is an issue in displaying multi-line code snippets, which is
independent of these changes, but wasn't apparent before. The issue is
visible in the demo section below, where the struct bodies are sometimes
not fully shown, and they should be. This issue is reported in #5499 and
will be solved in a separate PR.
## Demo (an excerpt 😄)
### Private struct field is inaccessible
### Struct cannot be instantiated
### Struct pattern must ignore inaccessible private fields
### Struct pattern has missing fields
### Errors temporarily turned into warnings
## 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
Bumps repo to 0.49.0, made this a major one after some thought as we
longer support beta-4 as tooling with this release.
Also ran `cargo update` as this is a breaking change
---------
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
Fixes#5398, #5374
Add examples to our `--help` cli. The examples are defined through the a
macro `forc::cli_examples { }` and each of these examples is part of the
the test suite of the crate. This is done to ensure the documentation is
always up to date or updated whenever the tests are not passing.
## 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: Braqzen <103777923+Braqzen@users.noreply.github.com>
## Description
This PR just moves the dir helpers that were in `forc-util` to
`sway-utils`. I need access to these methods in an upcoming PR and
having them in `forc-util` introduces a mind field of circular
dependencies.
## Description
This PR adds 3 things:
1. Adds a benchmark for the format LSP request.
2. Calls `session.wait_for_parsing();` before computing the `code_lens`
request. This fixes the original issue reported in #4893 where run
buttons where being placed incorrectly after formatting.
3. If a file open in a code editor contains unsaved changes we write a
lock file to `.forc/lsp_locks/`. This file is removed when the file is
saved and there are no pending changes. If `forc-fmt` is run in a
terminal we check if the path has a lock file associated with it. If
unsaved changes are detected we bail from formatting with an error
message instructing the user to save changes before continuing. See
video below.
75e6fddc-adbc-4796-aeb9-985574ae8dcc
closes#4893
## Description
This PR implements the decisions made in the [Expressive Diagnostics
RFC](https://github.com/FuelLabs/sway-rfcs/blob/master/rfcs/0011-expressive-diagnostics.md)
and adapts the existing diagnostics:
- _Issue_ is removed from the header and placed in code.
- _Help_ can also be in code.
- Wording is simplified.
Closes#5075.
## Demo (Before and After)
## 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.
---------
Co-authored-by: Anton Trunov <anton.a.trunov@gmail.com>
## Description
Take the cargo approach of ignoring patches of workspace members,
printing a warning, and only accepting patches defined at the workspace
root file.
Fixes#4448
## 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 the comments given in [this
PR](https://github.com/FuelLabs/sway/pull/4965#discussion_r1304890715)
- shows errors if a match arm variable is defined multiple times
The _issue_ is still shown in the header and the wording can be
simplified. This will be done in a separate PR, for all existing
diagnostics, as shown
[here](https://github.com/FuelLabs/sway/issues/5056#issuecomment-1698964837).
Closes#4963.
## Demo
## 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.
---------
Co-authored-by: Anton Trunov <anton.a.trunov@gmail.com>
Co-authored-by: João Matos <joao@tritao.eu>
## Description
Fixes#1645 by checking if there are any duplicate keys in sections. Any
duplication of keys will generate a parsing error that will bubble up to
the final user with some context on how to fix it.
The following `Forc.toml` file will fail:
```
[project]
authors = ["Cesar"]
entry = "main.sw"
license = "Apache-2.0"
name = "invalid"
[dependencies]
foo = "bar"
foo = "xxx"
```
The error that will be bubble up to the CLI output reads as follow:
```
Error: failed to parse manifest: duplicate 'foo' for key `dependencies` at line 7 column 1.
```
This pull request is an upgrade to a `fuel-core 0.20.1` release.
The biggest changes coming from this new release is a rework of how
AssetId is structured to support [granular asset
minting](https://github.com/FuelLabs/fuel-specs/pull/491). This means a
contract can mint and burn multiple AssetId's, and the ContractId !=
AssetId.
---------
Co-authored-by: bitzoic <bitzoic.eth@gmail.com>
Co-authored-by: Cameron Carstens <54727135+bitzoic@users.noreply.github.com>
Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>
Co-authored-by: Brandon Kite <brandonkite92@gmail.com>
Co-authored-by: Sophie <sophiedankel@gmail.com>
## 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.
