## 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
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.
```
## Description
Updates `forc new` and `forc init` welcome message to point to our new
documentation hub.
Co-authored-by: Joshua Batty <joshpbatty@gmail.com>
## Description
This changes addresses the issues introduced in #4878
The `error_emitted` pattern is replaced by a scoping method on `Handler`
that collects errors within a closure and will error out if new erros
are introduced.
All instances of introducing `ErrorEmitted` as a literal value have now
been replaced by passing arround the receipt of the error emission
through the error representing values. Some types from the AST had to be
moved to `sway-types` to avoid circular dependencies introduced by this
change.
This also repairs some of the discrepancies to emitted warnings
introduced in #4878, as well as rename some of the `Handler` methods.
Fixes#4885Fixes#4886
## 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
Change error handling to use `Handler` instead of the macro based
`CompileResult`.
Fix#2734
## 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
Closes#3926.
(edited by @kayagokalp to reflect latest status of the PR)
This PR adds IPFS support for forc-pkg. To do so, forc relies on
existing ipfs local node without embedding a node to forc itself. If
local system does not have an ipfs node running, a public gateway
(https://ipfs.io) is used as a fallback mechanism and packages are
fetched through that.
## Some Context and Future Work
For our package registry stuff to work properly we will eventually need
to host an IPFS node to make sure that our published packages are pinned
by at least one node in the network. That is the case as long as we
don't have a way to incentivize people pinning the packages they
published. What will happen is that a package will be published by a
developer and after we detect the published package our own IPFS node
will pin it to make sure it is always accessible.
Also some benchmarks are done for public gateway during development. It
looks like for initial fetch operations from public gateway spends some
time looking for the package pinned by the IPFS node simulating our
incoming fuel IPFS node which is explained above. It is manageable but
fetching from the fuel IPFS node is instant as it already got the
package pinned. We can consider falling back to our own node's gateway
api rather than a public one to smooth the process.
Finally maybe we can explore embedded ipfs node option as a follow-up,
due to the status of IPFS with Rust, it is not very obvious (maybe not
event possible atm) how to be able to be fully compatible with kubo, for
fetching/publishing our packages. But this is still an open question
worth exploring.
## Testing
### To test with a local node:
1. You can install kubo, you can follow the instructions in their
website while installing https://docs.ipfs.tech/install/command-line/
2. Run the `ipfs daemon` service with `ipfs daemon`
3. Add an ipfs source, I have a package already pinned by my IPFS node
that you can use:
```toml
[dependencies]
test_lib = { ipfs = "QmfZ3uH7dFEDkYN5RQfyu4m7L8uk8kGiLkNwzHqsrormSj" }
```
4. Run `forc build`
### To test public gateway fallback:
1. Either do this before starting `ipfs daemon` or stop your local
daemon with `ipfs shutdown`.
Add an ipfs source, I have a package already pinned by my IPFS node that
you can use:
```toml
[dependencies]
test_lib = { ipfs = "QmfZ3uH7dFEDkYN5RQfyu4m7L8uk8kGiLkNwzHqsrormSj" }
```
2. Run `forc build`
---------
Co-authored-by: kayagokalp <kaya.gokalp@fuel.sh>
## 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
Inspired by #4588
## 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>
## Description
Adds an initial benchmarking setup to CI, where a collection of
libraries from https://github.com/FuelLabs/sway-libs are compiled,
performance metrics generated and later pushed into a new repo:
https://github.com/FuelLabs/sway-performance-data
Closes https://github.com/FuelLabs/sway/issues/318.
## 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
Set experimental module privacy rules as the default and remove the
experimental flag.
Closes#4506
## 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
closes#3268.
This PR adds filtering capability to `forc-test` based on test names. Tests are executed if their name contains the given filter phrase.
## Description
As title says, this refactor existing code to pass the engines type to
more places, and adds a new query engine while at it.
The query engine in this form still does not do anything at all, but
will be populated next with the necessary bits for its purpose.
## 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 change mainly adds checks to enforce the new module privacy rules
and supporting changes for it.
Changes include updating std and core to use
public modules, updating the parser to allow the use of the `pub mod`
syntax and adding an error type for private modules.
This change is implemented behind a `--experimental-private-modules`
experimental flag and not enabled by default.
It implements part of https://github.com/FuelLabs/sway/issues/4446, the
`pub use` syntax is yet to be implemented.
## 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: Joshua Batty <joshpbatty@gmail.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
Implement https://github.com/FuelLabs/sway-rfcs/pull/23
Closes https://github.com/FuelLabs/sway/issues/3419 (technically via the
RFC)
Closes https://github.com/FuelLabs/sway/issues/3202
Closes https://github.com/FuelLabs/sway/issues/3043
Closes https://github.com/FuelLabs/sway/issues/2639
Closes https://github.com/FuelLabs/sway/issues/2465
Closes https://github.com/FuelLabs/sway/issues/4304
This is a big one but mostly removes stuff. It's hard to review but the
summary of changes below should be sufficient. Most of the changes here
are things that I just had to do to make CI pass.
- Removed the `--experimental-storage` flag and made its
[behavior](https://github.com/FuelLabs/sway/pull/4297) the default. Also
removed everything that was required for the previous storage APIs in
favour of the new ones.
- Break down the `std::storage` into multiple submodules:
- `storage_key` implements the API for `std::core::StorageKey`
- `storage_api` implements the free functions `read` (previously `get`),
`write` (previously `store`), and `clear`.
- 4 more modules for the dynamic storage types which now use the new
`StorageKey` API.
- `#[storage(write)]` now allows reading from storage as well. This is
needed because the way we pack structs in storage now requires that we
sometimes read from storage first if we were to write a portion of a
slot.
- Removed the "storage only types" checks and the corresponding tests.
- Removed the `__get_storage_key` intrinsic and the `get_storage_key` IR
instruction and all corresponding tests. Also removed the `state_index`
metadata as it is no longer required.
- Added tests and example to showcase nested storage maps and nested
storage vectors.
## 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: 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.
## Description
This PR introduces `StorageHandle` to the `core` as an **experimental**
feature. `StorageHandle` is a descriptor of a location in storage
containing two fields:
1. A key pointing to a storage slot `s`.
2. An offset pointing to a particular word in `s` or in its subsequent
slots. This offset is new and is not described in the RFC. I will
rectify that shortly.
The standard library introduces helper methods `read`, `try_read`, and
`write` to `StorageHandle` that allow reading from and writing to the
location pointed to by the handle. `try_read` returns an `Option`
wrapping the data while `read` automatically internally unwraps the data
and could panic.
The summary of this change is as follows:
* New struct `core::experimental::storage::StorageHandle`
* New storage library `std::experimental::storage::*` that should
eventually replace `std::storage::*`. This new library mirrors the old
one to the extent possible and introduces the helper methods for
`StorageHandle`. Other data structures such as `StorageVec` and
`StorageBytes` will be introduced in a separate PR.
* Add an experimental flag `--experimental-storage` to `forc` that
enables all the required code in the compiler to support `StorageHandle`
as described in the https://github.com/FuelLabs/sway-rfcs/pull/23.
* Type checking phases assumes the existence of `StorageHandle` and
monomorphizes it as needed.
* Storage accesses now always return `StorageHandle` and storage
reassignment are no longer relevant.
* IR gen handles storage accesses by "filling" the key and the offset in
an aggregate representing the `StorageHandle`. The key and the offset
are statically determined based on the index of the storage variable in
the `storage` block and the field accessed, if applicable.
* Storage initializers are now handled based on the new model
* The new approach packs struct fields by default but does not pack
across storage variables. This offers the most amount of flexibility.
This is a deviation from the RFC which I will update shortly.
* To implement `StorageMap` and other dynamic storage data structures,
we now write `impl StorageHandle<StorageMap<K, V>>` instead of `impl
StorageMap<K, V>` directly. Also, note that the `get` method now returns
a `StorageHandle` instead of the actual data. To get the actual data,
`read()` or `try_read()` should be called on the resulting handle. This
is needed for multiple reasons including proper support for nested
dynamic storage types. Rust also does the same, in a way (where `get`
actually returns ` &` which happens to coerce to the real data in
certain places).
* I added various tests but they're not comprehensive. Some tests on my
list:
* Extensive tests for storage maps in structs (which now work!)
* Extensive tests for storage accesses with various types and struct
layouts
I still need to figure out how to do nested dynamic storage types with
this approach. The stuff I have in `map_in_map_access` in
`test_projects/experimental_storage/src/main.sw` is just an attempt but
not ergonomic at all of course.
## Checklist
- [ ] 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).
- [ ] I have requested a review from the relevant team or maintainers.
## Description
closes#3953
This PR adds parallel test runners to improve our test execution times
by utilizing the fact that each test is actually completely separate
from each other. Also a flag `--test-threads` added to `forc-test` to
manually control number of thread used for execution.
Simple benchmarks taken from my local system with m1 max can be seen in
below: (
*Each config is executed 10 times)*
| Num Threads | Average Time |
| ----------- | ----------- |
| 1 | 1.019 ms |
| 2 | 938 ms |
| 4 | 883 ms |
As it can be seen speed-ups aren't great as this includes building as
well which is done with single thread. So I tested just building with
tests enabled on the same project (which is sway-lib-std btw) which
takes 810ms (again averaged 10 times). So after I normalize the results
above with this data
| Num Threads | Average Time |
| ----------- | ----------- |
| 1 | 209 ms |
| 2 | 128 ms |
| 4 | 73 ms |
Speed-ups are more visible with more complex tests with increased number
of tests.
## Description
graph.visualize now can include urls that are clickable in generated svg
files.
To set this up we can call forc with the argument
`--dca-graph-url-format`.
For vscode we would use: `--dca-graph-url-format
'vscode://file/{path}:{line}:{col}'`
This commit also changes forc `--dca-graph` to receive a path.
We still can output to std by using `--dca-graph ''`.
Also adds edge labels.
Also changes entry node shape to be different, a double octagon instead
of an ellipse.
## 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.
- [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#1636.
This PR introduces ssh authentication support for git sources. I also
started to maintain `git2_auth` which I aim to make a feature complete
authentication handler for git2-rs that supports non ssh-agent
interaction as well. That would take a lot more time so I pulled the
ssh-agent support and injected into `forc-pkg`. As I find out useful
things while experimenting on `git2_auth`, will update our
authentication handler with those as well.
1. We can now use dependencies in git ssh format
Example:
```TOML
std = { git = "git@github.com:FuelLabs/sway.git" }
```
2. We can also point to private repos
Co-authored-by: mitchmindtree <mitchell.nordine@fuel.sh>
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.
