## Description
This PR adds the `perf-diff-stats` recipe to the `justfile`. The recipe
calculates a simple statistics of performance improvements and
regressions obtained from the `perf-diff` recipe. The statistics
contains the _count_, _average_, _median_, _max_, and _min_ of
improvements and regressions and can be used to easily communicate
performance differences gained in a PR.
E.g.:
| | Improvements | Regressions |
| - | -: | -: |
| Count | 3 | 4 |
| Average | 8.13% | -2.21% |
| Median | 7.05% | -1.07% |
| Max | 12.86% | -6.12% |
| Min | 4.47% | -0.59% |
## Checklist
- [ ] 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).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] 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
This PR:
- Adds `--perf` and `--perf-only` options to `test` to collect gas
usages and bytecode sizes, and to run only the tests that actually
produce those performance data, respectively.
- Adds `[performance]` recipes to `justfile` that fully automate a
workflow for collecting and comparing performance data of the compiler
output.
`--perf` flag instructs `test` to collect performance data from tests of
categories `compile`, `run`, and `unit_tests_pass`. Collected gas usages
and bytecode sizes are written to files named
`<timestamp>-<category>-<build profile>-<branch>.csv`. E.g.:
`1020165605-e2e-bytecode-sizes-release-master.csv`.
When running tests in parallel (default option), performance data of
each individual `test --exact <test_toml_path>` process is written to a
piped stdout in JSON format. The main `test` process collects those JSON
outputs from all spanned processes.
The usual workflow of collecting and comparing performance data between
the `master` and feature branch is supported by the following `just`
recipes:
```console
[performance]
perf-e2e filter='' # collect gas usages and bytecode sizes from E2E tests [alias: pe2e]
perf-in-lang filter='' # collect gas usages from in-language tests [alias: pil]
perf-all filter='' # collect gas usages and bytecode sizes from all tests (E2E and in-language) [alias: pa]
perf-diff before after format='md' # generate performance diff between two CSV files [alias: pd]
perf-diff-latest format='md' # generate performance diffs between the latest two CSV files per testing category [alias: pdl]
perf-snapshot-historical path open='' # collect historic gas usages from a snapshot test that has a `forc test` output [alias: psh]
perf-list # list all performance files (*gas-usages-*.* and *bytecode-sizes-*.*) [alias: pl]
perf-remove # remove all performance files (*gas-usages-*.* and *bytecode-sizes-*.*) [alias: pr]
```
To obtain the performance comparison it is enough to run:
```console
just pa // `just perf-all`. On `master` to get the baseline.
just pa // `just perf-all`. On the feature branch to get the improved data.
just pdl // `just perf-diff-latest`. To get the diff of the last two collected performance data sets.
```
The `just` recipes should be executed from the root of the Sway
repository.
Aside from `--perf` writing to predefined files, all other parts of the
workflow are `just` recipes and can potentially be tailored to any other
workflow.
Adding support for collecting gas usages and bytecode sizes from other
tests like (snapshot, in-language, SDK harness) will be added in follow
up PRs.
## 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).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] 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
This is an optimization of contract calls on top of
https://github.com/FuelLabs/sway/pull/7440.
```csv
const_of_contract_call::cost_of_in_array_0,1976,1285
const_of_contract_call::cost_of_in_array_1,3164,1779
const_of_contract_call::cost_of_in_array_16,5096,4753
const_of_contract_call::cost_of_in_array_32,8421,8079
const_of_contract_call::cost_of_in_array_64,60382,14545
const_of_contract_call::cost_of_in_array_8,4724,4382
const_of_contract_call::cost_of_in_b256,2491,2147
const_of_contract_call::cost_of_in_bool,2627,2279
const_of_contract_call::cost_of_in_str_0,3043,2697
const_of_contract_call::cost_of_in_str_1,3345,2998
const_of_contract_call::cost_of_in_str_16,3374,3030
const_of_contract_call::cost_of_in_str_32,3572,3227
const_of_contract_call::cost_of_in_str_8,3768,3421
const_of_contract_call::cost_of_in_tuple_0,3822,3479
const_of_contract_call::cost_of_in_tuple_1,4392,4050
const_of_contract_call::cost_of_in_tuple_2,4761,4418
const_of_contract_call::cost_of_in_tuple_3,5104,4761
const_of_contract_call::cost_of_in_tuple_4,5468,5126
const_of_contract_call::cost_of_in_u16,4493,4141
const_of_contract_call::cost_of_in_u256,4777,4433
const_of_contract_call::cost_of_in_u32,4926,4582
const_of_contract_call::cost_of_in_u64,4934,4589
const_of_contract_call::cost_of_in_u8,4874,4526
const_of_contract_call::in_enum_u64,3186,2843
const_of_contract_call::in_enum_u64_u64,3061,2718
const_of_contract_call::in_enum_u64_u64_u64,3173,2830
const_of_contract_call::in_struct_u64,3635,3293
const_of_contract_call::in_struct_u64_u64,3897,3554
const_of_contract_call::in_struct_u64_u64_u64,4156,3813
const_of_contract_call::isolated_cost_of_in_array_0,956,956
const_of_contract_call::isolated_cost_of_in_array_1,1515,1185
const_of_contract_call::isolated_cost_of_in_array_16,3955,3266
const_of_contract_call::isolated_cost_of_in_array_32,6544,5471
const_of_contract_call::isolated_cost_of_in_array_64,9914,9914
const_of_contract_call::isolated_cost_of_in_array_8,3225,2728
const_of_contract_call::isolated_cost_of_in_b256,1462,1120
const_of_contract_call::isolated_cost_of_in_bool,1358,1047
const_of_contract_call::isolated_cost_of_in_str_0,1451,1140
const_of_contract_call::isolated_cost_of_in_str_1,1547,1237
const_of_contract_call::isolated_cost_of_in_str_16,1552,1241
const_of_contract_call::isolated_cost_of_in_str_32,1553,1242
const_of_contract_call::isolated_cost_of_in_str_8,1551,1241
const_of_contract_call::isolated_cost_of_in_tuple_0,820,820
const_of_contract_call::isolated_cost_of_in_tuple_1,1412,1090
const_of_contract_call::isolated_cost_of_in_tuple_2,1615,1304
const_of_contract_call::isolated_cost_of_in_tuple_3,1766,1455
const_of_contract_call::isolated_cost_of_in_tuple_4,1916,1605
const_of_contract_call::isolated_cost_of_in_u16,1428,1117
const_of_contract_call::isolated_cost_of_in_u256,1431,1120
const_of_contract_call::isolated_cost_of_in_u32,1554,1243
const_of_contract_call::isolated_cost_of_in_u64,1336,1025
const_of_contract_call::isolated_cost_of_in_u8,1352,1041
```
## Checklist
- [x] 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).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [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
This PR is a prequel for https://github.com/FuelLabs/sway/pull/7419.
It will set the baseline, which future PRs need to improve.
Apart from that it also:
1 - Fix a problem with `SubtsType` for `TyConstantDecl`;
2 - Introduce a new way to write snapshot tests. Now the test source
code can have "blocks"
```
/* START BOOL */
fn in_bool(v: bool) -> bool;
/* END BOOL */
```
These blocks can be manipulated from inside the `snapshot.toml`. In this
case, the `toml` is:
```
cmds = [
"forc test --path {root} --release --experimental const_generics",
{ repeat = "for-each-block", cmds = [
"forc test --path {root} --release --experimental const_generics"
] }
]
```
Which repeats the inner `forc test` for each block, removing all others.
That allows me to check the cost of the contract method selection
algorithm for each contract method.
For example, `cost_of_in_array_64` with all other contract methods costs
`60382`, but alone it only costs `58218`, which means that around 2000
was "wasted" in the contract method selection.
## 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).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [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.
- [ ] 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 brings all the scripts that we have, and push a couple more into
one `just` file (https://github.com/casey/just).
Initially we are just calling the script directly, but we can improve it
later.
## 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).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] 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
Introducing Forc-MCP module (CLI).
The MCP server can be run in 3 modes:
- `stdio`
- `sse`: long-running server - using http server-side-events
- `http`: long-running server - using http streams
### Forc-call integration
The first tool to be integrated is `forc-call` - which exposes the
following tool calls:
- `list_contract_functions`
- `transfer_assets`
- `get_execution_trace`
- `call_contract`
And the following resources:
- `MCP Type Encoding Reference`
- `MCP Tool Usage Examples`
- `Contract Examples with MCP Tools`
### Screenshots from `@modelcontextprotocol/inspector`
<img width="2543" height="549" alt="Screenshot 2025-07-15 at 5 09 16 PM"
src="https://github.com/user-attachments/assets/aaab5174-d5e6-4685-be71-fd17cd4f5d0f"
/>
<img width="2540" height="531" alt="Screenshot 2025-07-15 at 5 09 30 PM"
src="https://github.com/user-attachments/assets/9ab39d5a-950c-4404-a3a3-6e34b89f58e7"
/>
### Example usage (claude code)
Pre-requisites:
- Run local fuel-core node
```
fuel-core run --ip 127.0.0.1 --port 4000 --db-type rocks-db --debug
--historical-execution
```
- Deploy a contract to local node: `forc deploy --default-signer`
1. Run the MCP server (using http-steam in this example):
```
cargo run -p forc-mcp -- http
```
2. Add mcp server to claude
```
claude mcp add --transport http forc-mcp-http http://localhost:3001/mcp
```
3. Use claude/LLM to interact with MCP server
<details>
<summary>Claude output</summary>
```
╭───────────────────────────────────────────────────╮
│ ✻ Welcome to Claude Code! │
│ │
│ /help for help, /status for your current setup │
│ │
│ cwd: /Users/z/Desktop/fuellabs/sway │
╰───────────────────────────────────────────────────╯
> Use the forc-mcp-http.
Given the following sway contract:
demo/demo/src/main.sw
deployed at the following address:
ae40e8dbe366c5ac61fe558e4e9139300534cd5d9463522621a903464c441eb2
Using the forc-mcp-http:
> list all its callable functions.
> can you get the current count?
> tell me how much gas it would cost to increment the count.
> show me the execution trace for incrementing the count.
⎿ ⧉ Selected 14 lines from scratch/ai/templates.md in Cursor
⏺ I'll help you interact with the deployed Sway contract using forc-mcp-http. Let me start by reading
the contract to understand its structure, then perform the requested operations.
⏺ Read(demo/demo/src/main.sw)
⎿ Read 34 lines (ctrl+r to expand)
⏺ Now I need to find the ABI file for this contract to use with the forc-mcp-http tools:
⏺ Search(pattern: "demo/demo/out/**/*.json")
⎿ Found 7 files (ctrl+r to expand)
⏺ Perfect! I found the ABI file and a deployment file that matches the contract address. Let me read
the ABI:
⏺ Read(demo/demo/out/release/demo-abi.json)
⎿ Read 89 lines (ctrl+r to expand)
⏺ Now let me use the forc-mcp-http tools to interact with the contract. First, I'll list all callable
functions:
⏺ forc-mcp-http:list_contract_functions (MCP)(abi: "/demo/demo/out/rele
ase/demo-abi.json", contract_id: "ae40e8dbe366c5ac61fe55
8e4e9139300534cd5d9463522621a903464c441eb2")
⎿ Callable functions for contract: ae40e8dbe366c5ac61fe558e4e9139300534cd5d9463522621a903464c441eb2
get_count() -> u64
… +186 lines (ctrl+r to expand)
⏺ Now let me get the current count:
⏺ forc-mcp-http:call_contract (MCP)(abi: "/demo/demo/out/release/demo-a
bi.json", contract_id: "ae40e8dbe366c5ac61fe558e4e9139300534cd5d94
63522621a903464c441eb2", function: "get_count")
⎿ {
"tx_hash": "0f1e868e75530f33d37748cac9ae25c33bf166c9e02d28e36f3ffdd67ecf3584",
"total_gas": 65007,
… +354 lines (ctrl+r to expand)
⏺ Now let me check the gas cost for incrementing the count using dry-run mode:
⏺ forc-mcp-http:call_contract (MCP)(abi: "/demo/demo/out/release/demo-a
bi.json", contract_id: "ae40e8dbe366c5ac61fe558e4e9139300534cd5d94
63522621a903464c441eb2", function: "increment_count",
function_args: ["(1, 2)"], mode: "dry-run")
⎿ Error: Contract call failed: input must start with '{' and end with '}': (1, 2)
⏺ Let me fix the format for the struct argument:
⏺ forc-mcp-http:call_contract (MCP)(abi: "/demo/demo/out/release/demo-a
bi.json", contract_id: "ae40e8dbe366c5ac61fe558e4e9139300534cd5d94
63522621a903464c441eb2", function: "increment_count",
function_args: ["{\"vals\": [1, 2]}"], mode: "dry-run")
⎿ Error: Contract call failed: input must start with '(' and end with ')': "vals": [1, 2]
⏺ Let me try the tuple format as shown in the example:
⏺ forc-mcp-http:call_contract (MCP)(abi: "/demo/demo/out/release/demo-a
bi.json", contract_id: "ae40e8dbe366c5ac61fe558e4e9139300534cd5d94
63522621a903464c441eb2", function: "increment_count",
function_args: ["((1, 2))"], mode: "dry-run")
⎿ Error: Contract call failed: input must start with '{' and end with '}': ((1, 2))
⏺ Let me try with the correct struct format:
⏺ forc-mcp-http:call_contract (MCP)(abi: "/demo/demo/out/release/demo-a
bi.json", contract_id: "ae40e8dbe366c5ac61fe558e4e9139300534cd5d94
63522621a903464c441eb2", function: "increment_count",
function_args: ["{(1, 2)}"], mode: "dry-run")
⎿ {
"tx_hash": "f694c73230e893b00968d8106f5bafbcd585c2cf0f4aea1c6a562ce7e1868690",
"total_gas": 78940,
… +399 lines (ctrl+r to expand)
⏺ Perfect! Now let me get the execution trace for that increment operation:
⏺ forc-mcp-http:get_execution_trace (MCP)(total_gas: 78940, trace_events: [{"Call":{"index":0,"method
":"increment_count","arguments":["Adder { vals: (1, 2)
}"],"to":"ae40e8dbe366c5ac61fe558e4e9139300534cd5d9463522621
a903464c441eb2","amount":0,"gas":26222}},{"LogData":{"index"
:2,"id":"ae40e8dbe366c5ac61fe558e4e9139300534cd5d9463522621a
903464c441eb2","value":"3","len":8}},{"ReturnData":{"index":
4,"id":"ae40e8dbe366c5ac61fe558e4e9139300534cd5d9463522621a9
03464c441eb2","data":"()"}},{"Return":{"index":6,"id":"00000
00000000000000000000000000000000000000000000000000000000000"
,"val":1}},{"ScriptResult":{"index":7,"result":"Success","ga
s_used":22210}}])
⎿ Traces:
[Script]
├─ [26222] 0xae40e8dbe366c5ac61fe558e4e9139300534cd5d9463522621a903464c441eb2::
… +8 lines (ctrl+r to expand)
⏺ Summary
Here are the results for the deployed Sway contract at
ae40e8dbe366c5ac61fe558e4e9139300534cd5d9463522621a903464c441eb2:
Callable Functions:
1. get_count() → returns u64 (read-only)
3. increment_count(adder: Adder) → returns () (read/write storage)
Current Count:
The current count is 1
Gas Cost for Increment:
Incrementing the count with Adder { vals: (1, 2) } costs 78,940 gas total (22,210 gas used by
script)
Execution Trace:
The increment operation:
- Calls increment_count with Adder { vals: (1, 2) }
- Uses 26,222 gas for the contract call
- Emits a log with value 3 (0 + 1 + 2 = 3, the new count)
- Returns () (unit/void)
- Total script gas used: 22,210
- Result: Success
The contract adds the two values from the Adder struct (1 + 2 = 3) to the current storage count (0)
and logs the result.
```
</details>
## 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).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] 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: z <zees-dev@users.noreply.github.com>
## Description
This repo was [archived ](https://github.com/FuelLabs/forc-explorer )in
July 2024 but was not removed from CI or the docs.
I have update the plugins section of the documentation from forc explore
to `forc-install` which is a
[tool](https://github.com/DarthBenro008/forc-install) from a community
member.
## Checklist
- [x] I have linked to any relevant issues.
- [ ] 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] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] 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
Bumps fuel-vm, fuel-core fuels-rs and forc-wallet to latest versions.
Upgrades Rust to 2021 edition.
## 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] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [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.
- I believe this is non-breaking from user code perspective but I'm not
too sure about that
- [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: z <zees-dev@users.noreply.github.com>
Co-authored-by: zees-dev <63374656+zees-dev@users.noreply.github.com>
Co-authored-by: JoshuaBatty <joshpbatty@gmail.com>
Co-authored-by: IGI-111 <igi-111@protonmail.com>
## Description
This PR:
- implements partial equivalence in the `core::ops`, as explained in
detail in #6883. The implementation is opt-in and behind the
`partial_eq` experimental feature flag.
- implements `forc migrate` migration steps for automatic migration to
`partial_eq` feature.
- extends the infrastructure for writing `forc migrate` migrations.
- preserves `Annotation`s on `LexedModule`s in the `LexedProgram`.
(Those were before stripped off and not available in the compiled
`Programs`. This resulted in loss off `//!` doc-comments that are
represented as `doc-comment` annotations.)
Extensions in the `forc migrate` infrastructure include:
- possibility to postpone migration steps. This allows writing
multi-step migrations where the first step is usually early adopting an
experimental feature by using `cfg` attributes in code. This possibility
is crucial for migrating our own codebase where we want to early-adopt
and test and stabilize experimental features.
- possibility to match elements on both mutable and immutable parsed
trees. The initial assumption that immutable matching on typed trees
will always be sufficient does not hold. Experimental `cfg` attributes
can remove parts of typed trees that might be needed in analysis.
- `LexedLocate(As)Annotated` for easier location and retrieval of
`Annotated` elements.
- additional implementations of existing traits.
- additional `Modifier`s for modifying existing elements in the lexed
tree.
- `New` struct for convenient creation of often needed lexed tree
elements. Note that we do not expect migrations to generate large new
parts of lexed trees, but mostly to modify or copy and modify existing
ones.
Almost all of the changes in the Sway files are done automatically by
the migration steps. The only manual change was in the `core` library
(`std` library is also automatically migrated) and in slight extension
of two of the tests.
Note that some of the tests have `Eq` traits in trait constraints. As
explained in the #6883, it is not necessary to change those to
`PartialEq`. We might consider changing some of them, for testing
purposes, and such a change is done on one of the tests that was testing
the behavior of the `Eq` trait. But for the majority of the tests, there
is no strict need for switching from `Eq` to `PartialEq`.
Rolling `PartialEq` out in the tests provoked three existing issues that
will be fixed in separate PRs: #6897, #6898, #6899.
## 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).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [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
This PR introduces `forc-migrate`, a Forc tool for migrating Sway
projects to the next breaking change version of Sway.
The tool addresses two points crucial for code updates caused by
breaking changes:
- it informs developers about the breaking changes and **assists in
planing and executing** the migration.
- it **automatically changes source code** where possible, reducing the
manual effort needed for code changes.
Besides adding the `forc-migrate` tool, the PR:
- extends `Diagnostic` to support migration diagnostics aside with
errors and warnings.
- changes `swayfmt` to support generating source code from arbitrary
lexed trees. The change is a minimal one done only in the parts of
`swayfmt` that are executed by migration steps written in this PR.
Adapting `swayfmt` to fully support arbitrary lexed trees will be done
in #6779.
The migration for the `references` feature, migrating `ref mut` to
`&mut`, is developed only partially, to demonstrate the development and
usage of automatic migrations that alter the original source code.
The intended usage of the tool is documented in detail in the "forc
migrate" chapter of The Sway Book: _Forc reference > Plugins >
forc_migrate_. (The generated documentation has issues that are caused
by the documentation generation bug explained in #6792. These issues
will be fixed in a separate PR that will fix it for all the plugins.)
We expect the `forc-migrate` to evolve based on the developer's
feedback. Some of the possible extensions of the tool are:
- adding additional CLI options, e.g., for executing only specific
migration steps, or ignoring them.
- passing parameters to migration steps from the CLI.
- not allowing updates by default, if the repository contains modified
or untracked files.
- migrating workspaces.
- migrating other artifacts, e.g., Forc.toml files or contract IDs.
- migrating between arbitrary versions of Sway.
- migrating SDK code.
- etc.
`forc-migrate` also showed a clear need for better infrastructure for
writing static analyzers and transforming Sway code. The approach used
in the implementation of this PR should be seen as a pragmatic
beginning, based on the reuse of what we currently have. Some future
options are discussed in #6836.
## Demo
### `forc migrate show`
Shows the breaking change features and related migration steps. This
command can be run anywhere and does not require a Sway project.
```
Breaking change features:
- storage_domains (https://github.com/FuelLabs/sway/issues/6701)
- references (https://github.com/FuelLabs/sway/issues/5063)
Migration steps (1 manual and 1 semiautomatic):
storage_domains
[M] Review explicitly defined slot keys in storage declarations (`in` keywords)
references
[S] Replace `ref mut` function parameters with `&mut`
Experimental feature flags:
- for Forc.toml: experimental = { storage_domains = true, references = true }
- for CLI: --experimental storage_domains,references
```
### `forc migrate check`
Performs a dry-run of the migration on a concrete Sway project. It
outputs all the occurrences in code that need to be reviewed or changed,
as well as the migration time effort:
```
info: [storage_domains] Review explicitly defined slot keys in storage declarations (`in` keywords)
--> /home/kebradalaonda/Desktop/M Forc migrate tool/src/main.sw:19:10
|
...
19 | y in b256::zero(): u64 = 0,
| ------------
20 | z: u64 = 0,
21 | a in calculate_slot_address(): u64 = 0,
| ------------------------
22 | b in 0x0102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f20: u64 = 0,
| ------------------------------------------------------------------
|
= help: If the slot keys used in `in` keywords represent keys generated for `storage` fields
= help: by the Sway compiler, those keys might need to be recalculated.
= help:
= help: The previous formula for calculating storage field keys was: `sha256("storage.<field name>")`.
= help: The new formula is: `sha256((0u8, "storage.<field name>"))`.
= help:
= help: For a detailed migration guide see: https://github.com/FuelLabs/sway/issues/6701
____
Migration effort:
storage_domains
[M] Review explicitly defined slot keys in storage declarations (`in` keywords)
Occurrences: 3 Migration effort (hh::mm): ~00:06
references
[S] Replace `ref mut` function parameters with `&mut`
Occurrences: 0 Migration effort (hh::mm): ~00:00
Total migration effort (hh::mm): ~00:06
```
### `forc migrate run`
Runs the migration steps and guides developers through the migration
process.
## 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] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] 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
For #6179, PR #6501 kept bumping into errors as it was doing too many
things, so I've split that PR into multiple PRs. This is the first, and
the only thing it does is move all of the various `Cargo.toml`
dependencies into the single workspace `Cargo.toml`.
Future PRs will:
- Update dependency versions
- Update code that breaks from the version bumps
## 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] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [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
I noticed that the command section for forc in the documentation was
only showing headings and no information about the commands themselves.
See below.
This was due to back ticks being placed around the heading in #5369.
I've removed these ticks and added the commands to the list of accepted
words.
Also there were a lot of commands being missed due to their no longer
being subcommands, this logic has been updated and all the forc commands
are now being parsed.
## 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] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [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
Fixes Clippy warnings after updating to the latest stable Rust toolchain
(1.79).
## 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).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] 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
Update clap and deps to latest version
## 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] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [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
There's still a ton more to do but going to open this to get merged to
avoid conflicts. We can possibly add in some of these rules into CI in a
future PR.
## 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).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] 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.
## Description
Closes https://github.com/FuelLabs/sway/issues/5006
## Checklist
- [x] 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.
## Description
Closes https://github.com/FuelLabs/sway/issues/5008
The panic happened because the formatter was adding two `;`s after a
constant declaration inside of a trait.
I'm working toward the goal of making it so the formatter never panics,
even for sway files that do not compile.
I made it so, when a sway file does not compile, it does not cause the
formatter to panic. Now it prints an error message and returns that it
did not format anything with exit code 0.
I'm checking in this simple bash script that runs the formatter against
every sway project in the repo. Fixing this bug brought the # of panics
from ~35 down to 23.
I verified that the CI step that checks the formatting of sway docs is
still working.
## Checklist
- [x] 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.
## Description
closes#4757.
closes#4756.
This PR adds balance query capabilities to forc-deploy so that users can
select the desired account to use before signing their transaction.
Current output looks like:
```console
Please provide the password of your encrypted wallet vault at "/Users/kayagokalp/.fuel/wallets/.wallet":
Account 0 -- fuel1x6pc0g9gwp2c2hzhejlw7l4guqd99732zt2wd68j2ukrdu59kv9qqz9h3k:
Asset ID Amount
0000000000000000000000000000000000000000000000000000000000000000 4294967295
Please provide the index of account to use for signing:0
Do you accept to sign this transaction with fuel1x6pc0g9gwp2c2hzhejlw7l4guqd99732zt2wd68j2ukrdu59kv9qqz9h3k? [y/N]: y
Contract deploy_test_integration Deployed!
Network: http://127.0.0.1:4000
Contract ID: 0x73ea64a310b6fc2c9e6674a49f5515f01950d97cc845cb4149ececea6cbf4060
Deployed in block 0x45ee78fed1083c7734246cb93258dcdc865fc9bc13667b89088aeb43037
```
Also now forc-deploy throws an error for empty accounts:
```console
Please provide the password of your encrypted wallet vault at "/Users/kayagokalp/.fuel/wallets/.wallet":
Error: Your wallet does not have any funds to pay for the deployment transaction.
If you are deploying to a testnet consider using the faucet.
If you are deploying to a local node, consider providing a chainConfig which funds your account.
```
Once we integrate a nice TUI selection library the output could be more
interactive with up and down keys etc.
## Description
Generates the documentation for dependencies & small improvements to the
API.
These changes **DO NOT** create links between dependency docs and the main docs, but generates the dependency docs and ensures there are no conflicts when generating these docs.
What's new so far:
- [x] Programs get their own folders, just like `cargo doc`
- [x] Generates documentation for dependencies by default: Closes#4533
- [x] Fixes possible conflict with `assets` folder: Closes#4545
- [x] Removes old docs before generating new ones: Closes#4544
## 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.
---------
Co-authored-by: Chris O'Brien <eureka@noctua.attlocal.net>
## Description
fixes#4424closes#4424
## 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: Joshua Batty <joshpbatty@gmail.com>
## Description
resolves#2740closes#4157
> In order to give a better highlighting I picked the "meta" scope as
seen in [highlight.js
docs](https://highlightjs.readthedocs.io/en/latest/css-classes-reference.html)
>
> The ["Mode"
](https://highlightjs.readthedocs.io/en/latest/language-guide.html) I've
added provides the html class: _hljs-meta_ however, the result is a
white color for annotation (like plain text) and not a blue color as
requested in the issue.
>
> The solution I've found for this is to add an additional css file to
specify custom behavior for the desired class. I haven't added this file
because I think it's out of scope.
## 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: Mohammad Fawaz <mohammadfawaz89@gmail.com>
## Description
Applies the ayu theme to `<pre>` wrapped code blocks using the
`highlight.js` file used in the markdown books.
## Checklist
- [x] I have linked to any relevant issues. Closes#4175
- [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
This moves the examples workspace manifest introduced in #4118 into the
`examples/` directory and cleans it up a bit.
We also now integrate the examples workspace into CI, making the old
`examples-checker` script redundant. This old script is also removed as
a part of this PR.
## 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.
So far I'm addressing all Clippy warnings except for `result_large_err`:
Example:
```console
warning: the `Err`-variant returned from this function is very large
--> sway-core/src/semantic_analysis/namespace/items.rs:130:56
|
130 | pub(crate) fn check_symbol(&self, name: &Ident) -> Result<&ty::TyDeclaration, CompileError> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the `Err`-variant is at least 224 bytes
```
Addressing this seems like it will take some time. Might have to throw
in `Box` in various places. To unblock everyone from working, I'm
allowing `clippy::result_large_err` in CI for now.
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).
Add some missing keywords to the `sway.js` file. This was triggered by
@Braqzen noticing some inconsistent highlighting in the generated MD
books.
Doesn't address custom types not being highlighted but that can be for a
future PR.
* Copy over changes from PR#1669
* Rework `forc new` in terms of `forc init`
This removes all of the duplicated logic from the `forc new` command in
favour of re-using the `forc init` op.
* Add missing doc
* Add missing comment
Co-authored-by: Rashad Alston <rashad@Rashads-MacBook-Pro.local>
Co-authored-by: mitchmindtree <mitchell.nordine@fuel.sh>
Co-authored-by: Rashad Alston <rashad@Rashads-MBP.attlocal.net>
* Add instructions to update mdbook-forc-documenter if 'Commands' or 'Plugins' chapter names change
* replace forc gm example with forc explore, and add 'or plugin' after every reference to command
* Add instructions to add plugin installation within CI
* newline
* more info on taking action
* consistent wording
* Clearer wording on removing plugin
* fix: behaviour -> behavior
* Use permalinks
* use permalink in docs/README.d as well
* forc template resolves the HEAD and fetches the repo. Prints the requested directorie's path
* forc template works with and without template name
* forc init --template removed, pkg.rs unused pub modifier removed
* extra info added before copy, cargo-toml-lint, udeps fix, mdbook fix
* invoke CI
* Update scripts/mdbook-forc-documenter/examples/forc_template.md
Co-authored-by: John Adler <adlerjohn@users.noreply.github.com>
* Update scripts/mdbook-forc-documenter/examples/forc_template.md
Co-authored-by: John Adler <adlerjohn@users.noreply.github.com>
* default url provided, project_name is last parameter to pass without --project_name
* cargo fmt
* println to tracing::info
* local_repo_name to template_name
Co-authored-by: John Adler <adlerjohn@users.noreply.github.com>
* Refactoring to get ready for plugin documentation integration
* Check for errors when updating doucmentation
* Fix formatting of error text
* Remove unused BorrowMut
* Add plugin docs
* strip whitespace to remove version no. from plugin command header
* Better naming for commands/plugins within preprocessor
* extract inject_content
* handle parsing subcommand
* Refactor
* Install plugins within ci and gh-pages
* order plugins alphabetically
* official_plugin_commands -> plugin_commands, since they mean the same
* Handle error messages better
* subcommand_is_parsed -> has_parsed_subcommand_header for consistency
* More consistent expect message
* Add additional white spaces for test_format_subcommand_line
* cargo install --debug to speed things up
* Update input from &Vec<String> to &[String]
* Move forc-explore, forc-fmt, forc-lsp, into forc-plugins dir
* Update CI ymls with new plugins path
* Update all references to forc plugins in ci
* Programatically get plugins from forc-plugins
* Update ci.yml
* Properly install plugins
* Re-add removed cancel-previous-run
* Remove unused actions-rs/cargo
* Update plugins installation for gh-pages.yml
* Improve plugins.rs
* Improved find_forc_plugins_dir
* Remove return line within format_header_line
* Fix bug where preprocessor would panic if not in Sway root (#1618)
While testing, I noticed that the build would panic if you attempted to
`mdbook build` the book while in the `docs` directory. I then realised
we had a misuse of the `current_dir` function which must have slipped
through in a previous PR review. I've fixed this by adding a
`find_sway_repo_root` fn and implementing functions to find the plugins
and examples directories in terms of it.
Co-authored-by: mitchmindtree <mitchell.nordine@fuel.sh>
