576 commits

Author	SHA1	Message	Date
Joshua Batty	8103f0d02f	Migrate forc-tracing and forc-crypto to forc monorepo (#7507) ... ## Summary This PR completes the sway-side of migrating `forc-tracing` and `forc-crypto` to the new [forc monorepo](https://github.com/FuelLabs/forc), as outlined in [RFC #49](https://github.com/FuelLabs/sway-rfcs/pull/49). The corresponding forc repo PR: https://github.com/FuelLabs/forc/pull/119 ### Changes - Remove `forc-tracing` crate from workspace (now uses crates.io `0.71.1`) - Remove `forc-crypto` crate from workspace - Update CI to no longer build/package `forc-crypto` binary (it's now built from forc repo) - Update gh-pages workflow to install `forc-crypto` from forc repo for documentation generation ### Distribution Going forward, `forc-crypto` will be built and distributed from the forc repo by: - sway-nightly-binaries - fuelup - fuel.nix ### Documentation For now, documentation for all tooling will continue to live in this repo. The `gh-pages` workflow now pulls `forc-crypto` from the forc repo rather than building it locally, so docs generation continues to work as before.	2025-12-10 08:58:01 +11:00
Igor Rončević	8930fe8d5c	Bump to 0.70.2 (#7498) ... ## Description This PR bumps `forc` and `std` to v0.70.2. ## 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. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > Bumps Sway/Forc workspace and plugins to v0.70.2 and updates the gh-pages workflow to use Rust 1.90.0. > > - **Release/version bumps**: > - Set workspace `version` to `0.70.2` in `Cargo.toml`. > - Update internal crates/plugins (`forc*`, `sway*`, `sway-ir*`) dependency versions to `0.70.2`. > - Bump `sway-lib-std/Forc.toml` `version` to `0.70.2`. > - Refresh `Cargo.lock` with corresponding `0.70.2` crate versions. > - **CI**: > - `.github/workflows/gh-pages.yml`: Rust toolchain `1.86.0` → `1.90.0`. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit cbc2079fe4. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY -->	2025-11-19 06:53:05 -08:00
João Matos	6b26e50f09	Update to latest fuels-rs dependency (#7468) ... ## Description Update to latest `fuels-rs` dependency. ## 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. - [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. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > Upgrade to latest Fuel/fuels versions and refactor code/tests to new APIs (IDs, receipts, storage, wallet, node owner). > > - **Dependencies**: > - Bump `fuel-core` to `0.47.x`, `fuel-{vm,tx,types,asm,crypto}` to `0.65`, and `fuels{,-core,-accounts}` to `0.76`; update `fuel-core-*` crates across workspace and SDK harness. > - **Core/API migrations**: > - Use `Contract::id(..)` associated function (replaces instance method); update contract ID calculations in `forc-pkg`, `forc-client` deploy, and `forc-test`. > - Adjust receipts handling to `Arc<Vec<_>>` and convert as needed; update parsing/printing of `Receipt::LogData`/`ReturnData` to new byte accessors. > - Update `ContractsStateData` construction and storage conversions in VM trace storage. > - Refactor wallet account collection/types and secret key conversion in tx utils. > - Switch `forc-node` coin owner to `Owner` enum; update logging and tests. > - **Tests**: > - Adapt E2E and client tests to new receipt/data APIs and predicate fee assertions; update SDK harness deps and context tests (ContractIdExt import). > - **Misc**: > - Update workspace `Cargo.toml` and `test/src/sdk-harness/Cargo.toml`; extend `.typos.toml` ignores/excludes. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit d0541bd2ec806d10743310573edde8c85364b4ff. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY -->	2025-11-06 12:51:38 +00:00
Igor Rončević	01fc314744	Add --gas-costs option to forc-test and E2E test runner (#7471) ... ## Description This PR adds `--gas-costs` option to `forc-test` and E2E test runner. The option enables providing realistic gas costs to use for gas measurements during executions of tests and/or scripts. The gas costs can be provided from the following sources: - `built-in` Default value. It is hardcode in `forc test` based on the mainnet gas costs at the time of `forc` release. - `mainnet` Fetches the current gas costs from the mainnet using GraphQL. - `testnet` Fetches the current gas costs from the testnet using GraphQL. - `<FILE>` Reads the gas costs from a local JSON file. This PR implements only the `built-in` source and the remaining will be done in a follow up PR that will address #7472. The reason for adding gas costs is that both `forc test` and E2E test runner currently use `GasCosts::default()` when initializing the `Interpreter`. This can lead to very misleading gas cost interpretations. E.g, the default costs of `cfei`, `aloc`, `srwq`, and `swwq` are: ```console cfei: DependentCost::LightOperation { base: 2, units_per_gas: 214, }, aloc: DependentCost::LightOperation { base: 2, units_per_gas: 214, }, srwq: DependentCost::LightOperation { base: 47, units_per_gas: 5, }, swwq: DependentCost::LightOperation { base: 44, units_per_gas: 5, }, ``` Their on-chain costs, taken from the [Chain configuration repository](https://github.com/FuelLabs/chain-configuration/blob/master/upgradelog/ignition/consensus_parameters/6.json), are: ```console "cfei": { "LightOperation": { "base": 2, "units_per_gas": 562 } }, "aloc": { "LightOperation": { "base": 3, "units_per_gas": 562 } }, "srwq": { "HeavyOperation": { "base": 311, "gas_per_unit": 312 } }, "swwq": { "HeavyOperation": { "base": 7838, "gas_per_unit": 8156 } }, ``` The difference between the real on-chain cost and default parameters are significant, especially for `srwq` and `swwq`. In a general case, this difference can make gas usages printed by `forc test` or fetched by E2E `--perf` option very misleading, especially when used to benchmark performance. With the `--gas-costs` option we by default get the realistic, mainnet based built-in cost, and can even specify particular costs we want to have. ## 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) - [ ] 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.	2025-10-30 08:53:28 +11:00
Igor Rončević	46e83a6fbe	Add --perf option to test to collect and diff performance data (#7459) ... ## 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.	2025-10-21 18:41:35 +04:00
Igor Rončević	97efa221f0	Excute E2E tests in parallel (#7456) ... ## Description This PR implements parallel execution of E2E tests by using the approach similar to one introduced by @JoshuaBatty for running LSP garbage collection tests in parallel. The approach is based on: - `test` binary getting an additional `--exact` option used by the parallel runner to run exactly one test passed as an argument to `--exact`. The argument is the full path to the test's `toml` file. - parallel runner that uses `rayon` and `std::process::Command` to span `test --exact <test toml path>` processes in parallel. The original command line argument passed to `test` get forwarded to `test --exact` only if they are applicable while running tests in parallel. On my laptop with 20 cores, **the execution time of the complete E2E test suite reduces from reproducible 10:48 minutes to reproducible 1:47 minutes**. Parallel execution is set to be the default one. Sequential execution can still be used via `--sequential` or `-s` flag: `cargo run -- -s` or `test -s`. Similar to parallel garbage collection tests, the parallel execution of E2E tests shows `stderr` output of the executed tests, but not the `stdout`. Being non-deterministic, the position of displayed errors will not come immediately after or before the failing test display, but will always be easy to relate to a concrete failing test. In practice, this will be perfectly enough for troubleshooting failing tests. If all the output is needed during troubleshooting, failing tests can always be executed sequentially, by using the `--sequential` or `-s` flag. Additionally the PR: - adds `no_output` flag to `BuildOpts` to instructs `forc-pkg` not to output build artifacts like bytecode, ABI JSON, or storage slots JSON. This improves test execution speed in general because it skips writing to disc artifacts that are anyhow not used in tests. Also, it simplifies parallelization, because in case of tests with several `test.<feature>.toml` files, we don't need to worry about racing conditions when writing output files. If needed for troubleshooting, output can still be optionally generated in tests by passing the newly added `--write-output` CLI flag to the `test` binary. This flag is ignored when running tests in parallel. A support for the `no_output` option is not added neither to `forc` CLI, nor to CLI of any other tools like, e.g., `forc deploy`. If it proves useful to those tools, we can always easily add it to their CLIs. - fixes #7449 by annotating the `test` binary `main` function with `#[tokio::main(flavor = "current_thread")]`. - renames `exclude_std` CLI option to `no_std_only` to follow the `_only` pattern in naming filters in `FilterConfig` that filter out only the tests with a certain property. Implementing parallel execution for snapshot and IR tests (if required) will be done in followup PRs. ## 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) - [ ] 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.	2025-10-14 10:22:11 +11:00
kaya	107b092e9d	chore: bump version to v0.70.1 (#7454) ... ## Description Bumping version to release #7451 cc @ironcev I see that you couple large commits merged after 0.70.0, can you verify if they are breaking or not before we continue with merging this :)	2025-10-10 18:34:56 +11:00
Igor Rončević	3c6f718fe2	Remove fuels patches from workspace's Cargo.toml (#7452) ... ## Description This PR removes unused patches of `fuels` from workspace's `Cargo.toml` file. ## 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.	2025-10-10 00:11:41 +11:00
Igor Rončević	1da5e662e8	Compile runtime backtracing to ASM and compile-time to ABI JSON (#7387) ... ## Description This PR implements the compilation of the ABI backtracking, as described in the [ABI Backtracking RFC](https://github.com/FuelLabs/sway-rfcs/blob/ironcev/abi-backtracing/rfcs/0016-abi-backtracing.md). The PR closes two remaining implementation steps listed in the #7276: - Compile runtime backtracing to ASM and compile-time to ABI JSON - Support backtracing in forc test ### Changes in the ABI JSON and IR Compilation #### `panickingCalls` section in the ABI JSON Each panicking call is identified by a unique number and provided in the new `panickingCalls` section in the ABI JSON. E.g., for this panicking call in a module `some_module` of a package `some_package`: ```sway fn some_function() { let _ = this_function_might_panic(42); } ``` the following ABI JSON entry is created: ```json "panickingCalls": { "1": { "pos": { "function": "some_package::some_module::some_function", "pkg": "some_package@0.1.0", "file": "src/some_module.sw", "line": 4, "column": 8 }, "function": "some_other_package::module::this_function_might_panic" }, } ``` #### Encoding error code and backtrace in a `panic` revert code The generation of the `panic` revert code is changed. A `panic` revert code now encodes: - the information that the revert is generated by a `panic` expression, - the actual error code that can be located in the `errorCodes` section of the ABI JSON, - up to five panicking call IDs, encoded in the order of calling, that can be located in the `panickingCalls` section of the ABI JSON. The encoding of the `u64` revert code works as following: ```console 1_pppppppp_CCCCCCCCCCC_CCCCCCCCCCC_CCCCCCCCCCC_CCCCCCCCCCC_CCCCCCCCCCC ``` - The leading `1` denotes a revert code generated by a `panic` expression. Arbitrary user-defined revert codes will must have the starting bit set to `0` or in other words be less then or equal to `9223372036854775807₁₀ = 7FFFFFFFFFFFFFFF₁₆`. - The `pppppppp` denotes the error code in the `errorCodes` section of the ABI JSON, that identifies the actual `panic` location. - Each `CCCCCCCCCCC` section denotes a panicking call code in the `panickingCalls` section of the ABI JSON. The calls represent the callstack, where the right-most code is the code of the immediate function call in which the `panic` occurs. If all `C`s a zero it means no-call. This will happen if the actual call-depth is less then five calls. #### Calculating backtrace Ever non-entry function that can panic gets an additional function argument: `__backtrace: u64`. The `__backtrace` to pass to a panicking call is calculated at runtime by left-shift the existing `__backtrace` provided by the caller function and append/bitwise OR the unique panicking call ID of the exact panicking call. The ID of that exact panicking call is a compile-time, compiler-generated constant as explained above. The detailed mechanism with examples is provided in the "Runtime execution and bytecode and gas overhead" chapter of the [ABI Backtracking RFC](https://github.com/FuelLabs/sway-rfcs/blob/ironcev/abi-backtracing/rfcs/0016-abi-backtracing.md). ## Additional Changes The `panickingCalls` section of the ABI JSON can differ between `debug` and `release` builds which required adding support for different ABI JSON oracle files in test that `validate_abi`. The requirement to display a fully qualified function name in the panicking call and the backtrace resulted in adding flexibility to displaying functions and types in general. Adjusting affected tests was used as opportunity to remove unnecessary dependencies to the `std` and reduced `std` libraries in a large number of tests. Also, a cleanup is done in some parts of the code, like, e.g., removing code duplications. The PR implements these additional changes: - Implements `TyFunctionDisplay` and `TypeInfoDisplay` for configurable displaying of functions and types. Replacing current various custom implementations of displaying with these two types, mostly in error messages, will be done in separate PRs, with low priority. Also, display might be improved in some edge cases. There are TODOs left in code for such, and improvements will be done in separate PRs, with lower priority. - Displays full type names in warnings and errors, where expected. The PR intentionally temporarily switches to full type names in all errors and warnings by making that a default behavior in `impl DisplayWithEngines for TypeInfo`. This is done so that we can easily spot errors and warnings that should use specific `TyFunctionDisplay` and `TypeInfoDisplay` (tests will break) and adapt those in the follow up PR that will address #7389. That follow up PR will also address usages of type names in LSP. - Implements expressive diagnostics for `CompileError::MethodNotFound` and utilize `TyFunctionDisplay` for displaying all matching candidates. - Implements `Value::new_u64_constant` and removing duplicated code for a common scenario of creating an IR Constant of type `u64`. - Removes several unnecessary `clone()`s and `String` allocations. - Renames fields postfixed with `typeid` to follow more general naming convention for `TypeId` fields and parameters. - Removes unnecessary dependencies to `std` or reduced `std` libraries in tests. - Adds support for different `json_abi_oracle` files for `debug` and `release` build profiles. The `panickingCalls` part of the ABI JSON can vary depending on the build profile. A test that verifies ABI JSON now *must provide* expected oracles for both build profiles, unless a profile is unsupported via `unsupported_profiles` test option. An alternative was considered, to allow just a single oracle file if both `debug` and `release` oracles are the same. The reasoning for having two as mandatory even in that case was to gain more explicit test setup. We can change this upon feedback if needed. The oracles have a suffix of either `.debug.json` or `.release.json` and the name part is, as before, one of the following: - `json_abi_oracle` for obsolete old encoding, - `json_abi_oracle.<experimental feature>` for experimental features, - `json_abi_oracle_new_encoding` for new encoding without other experimental features. - Fixes #7386. - Fixes #7388. ## 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. - [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.	2025-10-09 08:45:51 +00:00
kaya	5256cd17aa	Revert feat: introduce fuel-telemetry macros (#7295) (#7451) ... ## Description Ran git revert to revert telemetry changes causing #7449 #7450	2025-10-09 19:27:37 +11:00
zees-dev	19495ef491	Bump fuel-core v0.46.0 (#7445) ... ## Description Current latest supported mainnet/testnet version of fuel-core is `v0.46.0`; update sway accordingly. ## 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>	2025-10-09 12:35:51 +13:00
IGI-111	74bab180db	Bump to 0.70.0 (#7438) ... Co-authored-by: Igor Rončević <ironcev@hotmail.com>	2025-10-04 08:26:46 +04:00
zees-dev	8c8a461f30	forc-node wasm32 removal (#7436) ... ## Description - Reconfigure the `forc-node` crate to drop the `wasm-executor` feature - disable fuel-core `default features`; explicit feature-set declaration - `forc-node` `local` CLI configurable args: - DB backend - debug mode - historical execution - PoA trigger directly - Adjust the local-node test harness to cover the newly surfaced CLI knobs. - Remove the `wasm32-unknown-unknown` build target from CI and GitHub Pages workflows. - Regenerate Cargo.lock after the dependency and feature changes. ## 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>	2025-10-03 10:17:49 +04:00
kaya	35757b6a58	feat: introduce fuel-telemetry macros (#7295) ... ## Description # Add telemetry opt-out support to forc-tracing This adds `fuel-telemetry` to `forc-tracing` with **opt-out functionality** for upstream tools like fuelup. ## Usage First, add it to the `forc-tracing` dependency: ```toml [dependencies] forc-tracing = { version = "0.47", features = ["telemetry"] } ``` Then use the `telemetry::*` glob, followed by the usual `tracing` macros, but with a `_telemetry` postfix: ```rust use forc_tracing::{ init_tracing_subscriber, println_green, println_red, println_yellow, telemetry::*, }; fn main() { init_tracing_subscriber(Default::default()); println_red("Stop"); println_yellow("Slow down"); println_green("Go"); error_telemetry!("Error message for InfluxDB"); warn_telemetry!("Warn message for InfluxDB"); info_telemetry!("Info message for InfluxDB"); debug_telemetry!("Debug message for InfluxDB"); trace_telemetry!("Trace message for InfluxDB"); } ``` This will output the following (note `DEBUG` and `TRACE` messages are filtered out because of `RUST_LOG=info`): ```bash > RUST_LOG=info ./target/debug/example Stop Slow down Go ``` We can then peek into telemetry files like the following: ```bash > cat ~/.fuelup/tmp/*.telemetry.* | while read line; do echo "$line" | base64 -d; echo; done 2025-03-06T19:53:24.923452000Z ERROR aarch64-apple-darwin:Darwin:23.6.0 forc-tracing:0.66.8:src/main.rs 0e3480f5-faab-48b8-a935-21ce90a6f028 auto: Error message for InfluxDB 2025-03-06T19:53:24.925348000Z WARN aarch64-apple-darwin:Darwin:23.6.0 forc-tracing:0.66.8:src/main.rs 0e3480f5-faab-48b8-a935-21ce90a6f028 auto: Warn message for InfluxDB 2025-03-06T19:53:24.925434000Z INFO aarch64-apple-darwin:Darwin:23.6.0 forc-tracing:0.66.8:src/main.rs 0e3480f5-faab-48b8-a935-21ce90a6f028 auto: Info message for InfluxDB 2025-03-06T19:53:31.335690000Z INFO aarch64-apple-darwin:Darwin:23.6.0 systeminfo_watcher:0.1.0:src/systeminfo_watcher.rs ec63b355-7862-47db-9ae3-de0cfcc094c8 poll_systeminfo: cpu_arch="arm64" cpu_brand="Apple M2 Pro" cpu_count=10 global_cpu_usage=15.85 total_memory=34359738368 free_memory=23388143616 free_memory_percentage=0.68 os_long_name="macOS 14.6.1 Sonoma" kernel_version="23.6.0" uptime=2482559 vm="" ci="" load_average_1m=4.52 load_average_5m=4.17 load_average_15m=3.86 ``` ## New: Telemetry Opt-Out Support This PR also adds opt-out functionality for telemetry, allowing upstream tools like fuelup to disable telemetry collection: **Changes:** - Added `--disable-telemetry` CLI flag to main forc binary - Added `FORC_DISABLE_TELEMETRY` environment variable support - Updated all telemetry macros to respect the disable flag - Added `init_telemetry()` function for proper initialization **Opt-out Usage:** ```bash # Disable via CLI flag forc --disable-telemetry build # Disable via environment variable FORC_DISABLE_TELEMETRY=1 forc build # For upstream tools like fuelup export FORC_DISABLE_TELEMETRY=1 fuelup toolchain install latest ``` **Code example with opt-out:** ```rust use forc_tracing::{init_telemetry, init_tracing_subscriber, TracingSubscriberOptions}; fn main() { let options = TracingSubscriberOptions { disable_telemetry: Some(true), ..Default::default() }; init_tracing_subscriber(options.clone()); init_telemetry(&options); // Telemetry macros will now be no-ops when disabled error_telemetry!("This won't be sent to telemetry if disabled"); } ``` The implementation ensures telemetry is opt-out by default but can be easily disabled through either CLI flags or environment variables, making it suitable for upstream tool integration.	2025-10-03 14:22:42 +13:00
kaya	a1300bae7d	chore: bump version to v0.69.6 (#7425) ... ## Description Bump version to v0.69.6 after failed attempts.	2025-09-29 12:10:34 -07:00
IGI-111	b7378b39f6	Bump to v0.69.5 (#7417) ... Co-authored-by: kaya <20915464+kayagokalp@users.noreply.github.com>	2025-09-29 11:53:17 +10:00
IGI-111	a2c0531ab7	Bump to v0.69.4 (#7410)	2025-09-24 20:09:25 +04:00
IGI-111	ec6f0ca5c7	Bump to v0.69.3 (#7407)	2025-09-23 11:52:34 +00:00
IGI-111	9c125f6bf0	Bump to v0.69.2 (#7403) ... Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2025-09-23 02:09:01 +04:00
kaya	b552ba17c8	feat: improved reliability for failing fetches through forc-pkg (#7377) ... ## Description closes #7376 and TOOL-681 **Problem**: When registry package fetching fails, the created directory remains in ~/.forc/registry/, causing subsequent builds to fail because forc assumes the directory contains a valid package. To mitigate this: - *Moved directory creation:* Directory creation now happens after validating the package exists in the registry index. - *Added cleanup guard*: Used scopeguard::guard to ensure automatic cleanup if fetch fails. - *Implemented proper error handling*: On successful fetch, the guard is defused; on failure, the directory is automatically removed. ### Testing - `test_fetch_directory_cleanup_on_failure` validates that failed fetches properly clean up directories	2025-09-10 12:31:41 +12:00
zees-dev	1f9880f60d	refactor: forc-node as lib (#7353) ... ## Description This PR fundamentally refactors the `forc-node` plugin architecture by embedding the Fuel Core node directly as an in-process library rather than spawning it as a subprocess. This architectural change modernizes the forc-node plugin and lays the groundwork for advanced local development features. ## 🔄 Changes Overview ### Core Architectural Changes - **In-Process Execution**: Fuel Core now runs within the same process as the plugin, eliminating subprocess management overhead - **Direct Integration**: Replaced subprocess spawning with direct library calls to fuel-core - **Unified Logging**: Consolidated logging and error handling across all execution modes - **Improved Configuration**: Enhanced configuration display and management for better debugging ### Dependency Updates - Added direct fuel-core dependencies - Added fuel-core-chain-config for configuration management - Integrated tracing and tracing-subscriber for improved logging - Updated Cargo.lock with necessary transitive dependencies ## 💡 Motivation ### Current Limitations - Subprocess management adds complexity and potential failure points - Limited ability to extend node functionality - Difficult to implement advanced features like state forking (planned feature) ### Benefits of This Change 1. **Performance**: Eliminates IPC overhead and reduces startup time 2. **Reliability**: Direct function calls are more reliable than subprocess communication 3. **Extensibility**: Easier to add advanced features in future PRs ## 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> Co-authored-by: Joshua Batty <joshpbatty@gmail.com> Co-authored-by: kaya <20915464+kayagokalp@users.noreply.github.com>	2025-09-04 05:02:26 +00:00
zees-dev	6bdfa0c10f	feat: forc-call debugger integration (#7323) ... ## Description This PR adds interactive debugging capabilities to the `forc call` command, enabling developers to debug contract function calls step-by-step after transaction execution. The `--debug` flag is added to the `forc call` command that launches an interactive debugging session after transaction execution. The integration automatically handles transaction/ABI data and launches `forc-debug` for step-by-step debugging. ### Implementation - New `--debug` flag in `forc call` command - `start_debug_session()` function that creates temporary transaction/ABI files and launches the debugger - Integration with existing `forc-debug` functionality via the `start_tx` command ### Usage ```bash forc call 0x0dcba78d7b09a1f77353f51367afd8b8ab94b5b2bb6c9437d9ba9eea47dede97 \ --abi ./contract-abi.json \ get_balance 0x0087675439e10a8351b1d5e4cf9d0ea6da77675623ff6b16470b5e3c58998423 \ --debug ``` This drops users into an interactive debugging session to step through execution, inspect values, and set breakpoints. ### Notes - No breaking changes - feature is additive with optional flag - Temporary files are automatically cleaned up using `tempfile` crate - Zero overhead when `--debug` flag is not used <img width="1070" height="298" alt="image" src="https://github.com/user-attachments/assets/f48e8c7f-063b-4869-b690-810ddb7143cd" /> Addresses https://github.com/FuelLabs/sway/issues/7321. ## 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. --------- Co-authored-by: z <zees-dev@users.noreply.github.com> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>	2025-08-14 16:48:50 +12:00
zees-dev	8b29cc39c5	feat: forc-mcp auth for mcp server hosting (#7300) ... ## Description This PR introduces api-key based auth (and management endpoints for an admin account) for the `forc-mcp` HTTP server. Functionality includes: - Admin-only API key management endpoints for creating, listing, viewing, and deleting API keys - Enhanced rate limiting with separate limits for public and authenticated requests - Flexible authentication modes supporting both public access and API-key-only operation The docs have been updated with details on how to add MCP server with auth for claude and cursor. Addresses https://github.com/FuelLabs/sway/issues/7301 <details> <summary>Admin Endpoints</summary> All admin endpoints require authentication with an admin API key via `X-API-Key` header: #### `POST` `/admin/api-keys` - Creates new user-level API keys - Returns the generated API key (shown only once for security) - Generated keys use secure SHA256 hashing with `mcp_` prefix #### `GET` `/admin/api-keys` - Lists all API keys with usage statistics - Optional include_admin=true query parameter to include admin keys - Shows real-time usage counters and rate limit status #### `GET` `/admin/api-keys/{key_id}` - Retrieves details for a specific API key - Returns `404` for admin keys to maintain security - Includes current usage statistics #### `DELETE` `/admin/api-keys/{key_id}` - Deletes specific API keys - Prevents deletion of admin keys (returns 403) - Returns `204` on successful deletion #### `POST` `/admin/import` - Bulk imports API keys with historical usage data - Supports merge mode (default) or replace mode with `clear_existing: true` - Useful for migration or backup restoration </details> ### Dual-Tier Rate Limiting System #### Public Requests (no API key): - Default: `10` requests/minute, `1,000` requests/day - Tracked by client IP address #### Authenticated Requests (with API key): - Default: `120` requests/minute, `10,000` requests/day - Admin keys have unlimited access - Tracked per API key with usage persistence #### Intelligent Counter Reset Logic - Per-minute counters reset after `60` seconds - Daily counters reset at midnight (UTC date change) ### Authentication Modes - Mixed Mode (Default) - Allows both public and authenticated access - Public requests get lower rate limits - API key holders get higher rate limits - API Keys Only Mode - Set `api_keys_only: true` in configuration - Rejects all requests without valid API key - Suitable for production deployments requiring authentication ### Testing - Unit tests for authentication middleware - Integration tests for admin endpoints - Rate limiting validation tests - API key lifecycle tests (create, use, delete) - Security tests (unauthorized access, role escalation) - Persistence tests (file storage, restart recovery) ## 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. - [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: z <zees-dev@users.noreply.github.com> Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2025-07-31 18:13:37 +12:00
Mike Christopher	688242c07f	feat: check file descriptor limits before running forc node (#7302) ... ## Description Adds a check to try and set the `NOFILE` limit on Unix-based systems. This is important for RocksDB, since we generally exceed the default maximum number of allowed file descriptors allowed by the OS. The idea is to attempt to raise that limit to a reasonable number, and throw an error if we are unable to (likely due to user permission issues). ## 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.	2025-07-31 11:31:43 +10:00
Joshua Batty	c7ff31207a	Add parallel processing to forc-doc using rayon to improve performance (#7296) ... ## Description Key changes: - Parallelize document rendering and link generation - Add type aliases for complex nested types (`DocLinkMap`, `ModuleMap`, `RenderResult`) - Remove unnecessary wrapper functions and clones The parallel processing maintains insertion order through sequential merging, ensuring identical documentation output. Not sure why the codspeed report isn't showing this below but when I run `cargo bench` locally i'm seeing these results. | Metric | Before | After | Improvement | |--------|--------|-------|-------------| | build_std_lib_docs | 70.069 ms | 43.227 ms | **43.2% faster** | ## 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.	2025-07-30 14:21:46 +04:00
zees-dev	4c9c4c29bf	feat: forc mcp server - with forc-call tool integration (#7284) ... ## 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>	2025-07-24 08:18:31 -07:00
kaya	8963312ba8	feat: add preliminary local checks for forc-publish (#7253) ... ## Description closes #7252. This pull request introduces enhancements to the `forc-publish` plugin, focusing on validating project configurations and improving error handling. Key changes include the addition of a `validate` module for preemptive checks, updates to error definitions, and modifications to the tarball creation logic to incorporate validation. New test cases and sample data directories have also been added to ensure robust validation functionality. ### Validation Enhancements: * Added a new `validate` module in `forc-publish/src/validate.rs` to check for missing `Forc.toml`, missing version fields, and unsupported dependency types. * Updated the `Error` enum in `forc-publish/src/error.rs` to include new error variants for validation failures like `InvalidForcToml`, `MissingVersionField`, and `DependencyMissingVersion`. ### Tarball Creation Updates: * Refactored `create_tarball_from_current_dir` in `forc-publish/src/tarball.rs` to use the new `validate_dir` function for preemptive validation. Removed redundant checks for `Forc.toml` existence. * Adjusted test cases in `forc-publish/src/tarball.rs` to use sample directories with predefined configurations for validation testing. [[1]](diffhunk://#diff-e3f20cadab3a1cf99fc967e0adc12e908f435a185e1529df9b152388927adf45L79-R85) [[2]](diffhunk://#diff-e3f20cadab3a1cf99fc967e0adc12e908f435a185e1529df9b152388927adf45L140-R135) ### Test Data Additions: * Added sample directories under `tests/data` for various validation scenarios, including projects with missing versions, dependencies without versions, and valid configurations. [[1]](diffhunk://#diff-b171d6da23a1fe36735cd962cfcf506831115c3714654236b31dd999c2853823R1-R11) [[2]](diffhunk://#diff-016348eaea4a95d041537b29d370619ab0d5ca99cc84f9b30d8ad561aa757a1eR1-R9) [[3]](diffhunk://#diff-0495f782769450a8c200fdcc1f29805f4811a26f4849720fa34d5b37ba45e471R1-R8) * Included `.gitignore` files in test data directories to exclude `out` and `target` folders.	2025-07-22 02:03:58 +00:00
Daniel Frederico Lins Leite	0339852289	Better observability for the compiler (#7250) ... ## Description Whilst finishing "const generics" I spent a LOT of time trying to find why some cases where not working. Until I found the issue on a "indirect input" for the method `type_check_method_application`. The issue is that some other method was returning a wrong value, and although the solution is not hard, there is no way to fix just this problem, and there is no way to assert this returned value to guarantee that the problem will not return. To start to improve these kind of tests, and help debug problems, this PR start to create a "callback" mechanism that allows anyone using the compiler as a library, this will not be available at the CLI, to inspect and control logging. The integration in out e2e test harness is done by the `test.toml`. ``` category = "run" expected_result = { action = "return", value = 1 } expected_result_new_encoding = { action = "return_data", value = "0000000000000001" } validate_abi = true logs = """ if pkg != "std" && event == "on_before_method_resolution" && method == "len_xxx" { print_args(); trace(true); } if pkg != "std" && event == "on_after_method_resolution" && method == "len_xxx" { print_args(); trace(false); } """ ``` The `harness` framework will not call "logs" for every callback that happens outside of the "std" library. To allow interaction with the harness itself, some commands are available: - `print_args` print all the available arguments for that event on the "snapshot"; - `trace` enables/disables trace level logging, that also end up in the "snapshot". In the example above, we will generate the following snapshot: ``` --- source: test/src/e2e_vm_tests/harness_callback_handler.rs assertion_line: 14 --- on_before_method_resolution: FromModule { method_name: len_xxx }; Regular([]); S<unresolved T -> u64, N -> 3> before get_method_safe_to_unify: S<unresolved T -> u64, N -> 3> len_xxx<N -> None>(self: unresolved Self -> S<unresolved T -> T, N -> None>): u64 -> u64 after get_method_safe_to_unify: S<unresolved T -> u64, N -> 3>; len_xxx<N -> 3>(self: unresolved Self -> S<unresolved T -> u64, N -> None>): u64 -> u64 on_after_method_resolution: FromModule { method_name: len_xxx }; Regular([]); S<unresolved T -> u64, N -> 3>; len_xxx<N -> 3>(self: unresolved Self -> S<unresolved T -> u64, N -> None>): u64 -> u64; S<unresolved T -> u64, N -> 3> on_before_method_resolution: FromModule { method_name: len_xxx }; Regular([]); S<unresolved T -> u64, N -> 3> before get_method_safe_to_unify: S<unresolved T -> u64, N -> 3> len_xxx<N -> None>(self: unresolved Self -> S<unresolved T -> T, N -> None>): u64 -> u64 after get_method_safe_to_unify: S<unresolved T -> u64, N -> 3>; len_xxx<N -> 3>(self: unresolved Self -> S<unresolved T -> u64, N -> None>): u64 -> u64 ``` The important part is that the problem I want to fix it's there. On the line of "get_method_safe_to_unify", the "self" parameter const generic argument "N" is not being materialized, although the method resolution pass started with a fully materialized type. With this callback machinery it becomes easier to debug the problems, and possible to generate asserts to internal methods. ## 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. - [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.	2025-07-18 07:24:32 +00:00
IGI-111	b68a3861db	Bump to v0.69.1 (#7289)	2025-07-17 11:48:56 -07:00
Daniel Frederico Lins Leite	384f46f61d	Contract self impl (#7275) ... ## Description Continuation of https://github.com/FuelLabs/sway/pull/7030. ## 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. --------- Co-authored-by: hey-ewan <ewanretorokugbe@gmail.com> Co-authored-by: ewan ✦ <66304707+hey-ewan@users.noreply.github.com> Co-authored-by: IGI-111 <igi-111@protonmail.com>	2025-07-11 11:02:37 +00:00
kaya	403a7e5780	feat: add mdbook preprocessing for forc-publish to flatten include directives (#7264) ... ## Description closes #7263 This pull request introduces functionality to preprocess Markdown files by handling `{{#include}}` directives, enabling the inclusion of content from other files. It also integrates this functionality into the `forc-publish` plugin to process `README.md` files during tarball creation. The most important changes include the addition of the Markdown preprocessing module, updates to error handling, and modifications to the tarball creation process. ### Markdown Preprocessing Functionality: * [`forc-plugins/forc-publish/src/md_pre_process/mod.rs`](diffhunk://#diff-1d065227f3eea45f66a3189882f220de977df2e1b7d1fb2de36d2b9baeb39a7aR1-R293): Added a new module to preprocess Markdown files, including features like dependency graph construction, topological sorting, and content flattening for `{{#include}}` directives. Includes comprehensive tests for edge cases like cycles and missing includes. * [`forc-plugins/forc-publish/src/md_pre_process/error.rs`](diffhunk://#diff-2cb6edf1287489eb7edd794db5e8b727907a28755871f656cfce877aadd886c2R1-R25): Introduced a dedicated error type `MDPreProcessError` to handle issues like I/O errors, missing include files, and cycles in Markdown dependencies. ### Integration with `forc-publish` Plugin: * [`forc-plugins/forc-publish/src/lib.rs`](diffhunk://#diff-8b5115a5299062687979272a86a86b573a688194c06c044174da61798ef41574R4): Registered the new `md_pre_process` module in the plugin library. * [`forc-plugins/forc-publish/src/tarball.rs`](diffhunk://#diff-e3f20cadab3a1cf99fc967e0adc12e908f435a185e1529df9b152388927adf45R29-R31): Updated the tarball creation process to preprocess `README.md` files using the `flatten_markdown` function. Added a warning mechanism to log errors without failing the publish process. [[1]](diffhunk://#diff-e3f20cadab3a1cf99fc967e0adc12e908f435a185e1529df9b152388927adf45R29-R31) [[2]](diffhunk://#diff-e3f20cadab3a1cf99fc967e0adc12e908f435a185e1529df9b152388927adf45R44-R60) ### Error Handling Enhancements: * [`forc-plugins/forc-publish/src/error.rs`](diffhunk://#diff-d09f44c4690282b827488db75a21e561e1e6fa72d549904db3f5fc4313f4819cR34-R36): Extended the `Error` enum to include `MDPreProcessError` for better error propagation during Markdown preprocessing. ### Dependency Updates: * [`forc-plugins/forc-publish/Cargo.toml`](diffhunk://#diff-2bd34a7b1fa0f1850ad25c6e080d410b2df98c16b6cd75445a138d04e617311aR29): Added `regex` as a workspace dependency to support Markdown parsing.	2025-07-09 10:18:31 +04:00
Joshua Batty	ceedc94283	Add criterion benchmark to forc-doc + initial code quality pass (#7242) ... ## Description Doing some general code quality changes at the same time. ## 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.	2025-06-30 08:34:43 +00:00
zees-dev	0ac606c132	forc-call detailed vm-interpreter call traces (#7251) ... ## Description This PR updates the `forc call` functionality to provide detailed call traces. This is achieved via retrieving `Vec<StorageReadReplayEvent>` from transactions (dry-run and/or live mode) and executing these in a vm-interpreter. - The approach is inspired by code snippets from this repo: https://github.com/FuelLabs/execution-trace ### Additional `forc-call` updates: - introduction of contract address labelling via `--label <contract-addr>:<name>` - introduction of providing additional contract abis via `--contract-abi <contract-addr>:<abi-file-or-url>` #### Example Assume the following 2 contracts - where `demo-caller` calls `demo` contract: - `demo`: `0xe84e278cb083a5b3ff871f1d3de26fdd13ae044070e1bbda18b60a13f98bb295` - `demo-caller`: `0xed4437b191cc78a02df048f21a73df37f1627efdde7d7e4232468b9de9d83485` <details> <summary>demo contract source</summary> ```sway contract; use std::{logging::log}; struct Adder { vals: (u64, u64), } abi Demo { #[storage(read)] fn get_count() -> u64; #[storage(read, write)] fn increment_count(adder: Adder); } storage { count: u64 = 0, } impl Demo for Contract { #[storage(read)] fn get_count() -> u64 { storage.count.read() + 1 } #[storage(read, write)] fn increment_count(adder: Adder) { let new_count = storage.count.read() + adder.vals.0 + adder.vals.1; storage.count.write(new_count); log(new_count); } } ``` </details> <details> <summary>demo-caller contract source</summary> ```sway contract; use std::contract_id::ContractId; struct Adder { vals: (u64, u64), } abi Demo { #[storage(read)] fn get_count() -> u64; #[storage(read, write)] fn increment_count(adder: Adder); } abi DemoCaller { #[storage(read, write)] fn call_increment_count(adder: Adder) -> u64; #[storage(read)] fn check_current_count() -> u64; } const CONTRACT_ID = 0xe84e278cb083a5b3ff871f1d3de26fdd13ae044070e1bbda18b60a13f98bb295; impl DemoCaller for Contract { #[storage(read, write)] fn call_increment_count(adder: Adder) -> u64 { let demo = abi(Demo, CONTRACT_ID); demo.increment_count(adder); log("incremented count"); log(demo.get_count()); log("done"); demo.increment_count(Adder { vals: (5, 2) }); demo.get_count() } #[storage(read)] fn check_current_count() -> u64 { let demo = abi(Demo, CONTRACT_ID); demo.get_count() } } ``` </details> **Previous functionality**: ```sh cargo run -p forc-client --bin forc-call -- \ --abi ./demo/demo-caller/out/release/demo-caller-abi.json \ ed4437b191cc78a02df048f21a73df37f1627efdde7d7e4232468b9de9d83485 \ call_increment_count "{(1,1)}" -vvv ``` **Output**: <img width="721" alt="Screenshot 2025-06-24 at 12 14 53 PM" src="https://github.com/user-attachments/assets/2ef77293-54eb-46c3-989a-b7f8cf9d236c" /> **Updated functionality**: ```sh cargo run -p forc-client --bin forc-call -- \ --abi ./demo/demo-caller/out/release/demo-caller-abi.json \ ed4437b191cc78a02df048f21a73df37f1627efdde7d7e4232468b9de9d83485 \ --contract-abi e84e278cb083a5b3ff871f1d3de26fdd13ae044070e1bbda18b60a13f98bb295:./demo/demo/out/release/demo-abi.json \ --label ed4437b191cc78a02df048f21a73df37f1627efdde7d7e4232468b9de9d83485:demo-caller \ --label e84e278cb083a5b3ff871f1d3de26fdd13ae044070e1bbda18b60a13f98bb295:demo \ call_increment_count "{(1,1)}" -vv ``` **Output**: <img width="760" alt="Screenshot 2025-06-24 at 12 15 25 PM" src="https://github.com/user-attachments/assets/442c0a97-80f8-46b6-bdf9-d67952c28b58" /> ### Other misc. improvements to `forc-call` - refactor of the forc-call verbosity levels and functions (arguably cleaner code) - re-write of the tracing to simply process receipts and indent via stack - instead of recursively constructing node-call tree - closes https://github.com/FuelLabs/sway/issues/7197 ## AI description This pull request introduces significant enhancements to the `forc call` functionality, improving usability, debugging, and trace readability for multi-contract interactions. The changes include support for labeled contract addresses, additional ABI files for better decoding, and updates to verbosity levels. Additionally, dependencies and internal parsing logic have been updated to support these features. ### Enhancements to `forc call` functionality: * **Support for labeled contract addresses:** - Added the `--label` flag to allow users to assign human-readable labels to contract addresses in transaction traces, improving readability. [[1]](diffhunk://#diff-466e2f9659cab303594eb73a846768ecdbc1a13030e5869cdac51ddde87dd313R289-R302) [[2]](diffhunk://#diff-4ee92d729fce66f7e7aed1fc29b41834951eb63198e0da747b9b9e45d13f717bR248-R320) - Updated documentation to include examples of using labels in traces. [[1]](diffhunk://#diff-4ee92d729fce66f7e7aed1fc29b41834951eb63198e0da747b9b9e45d13f717bR63-R73) [[2]](diffhunk://#diff-466e2f9659cab303594eb73a846768ecdbc1a13030e5869cdac51ddde87dd313R184-R193) * **Support for additional ABIs:** - Introduced the `--contract-abi` flag to specify additional contract ABIs for decoding function signatures, parameters, and return values in multi-contract interactions. [[1]](diffhunk://#diff-466e2f9659cab303594eb73a846768ecdbc1a13030e5869cdac51ddde87dd313R289-R302) [[2]](diffhunk://#diff-466e2f9659cab303594eb73a846768ecdbc1a13030e5869cdac51ddde87dd313R209-R217) - Updated the parsing logic to handle additional ABIs and labels. - Documentation now includes examples and explanations for using additional ABIs. [[1]](diffhunk://#diff-4ee92d729fce66f7e7aed1fc29b41834951eb63198e0da747b9b9e45d13f717bR102-R115) [[2]](diffhunk://#diff-4ee92d729fce66f7e7aed1fc29b41834951eb63198e0da747b9b9e45d13f717bR248-R320) * **Improved verbosity and tracing:** - Adjusted verbosity levels to make transaction traces available at `-vv` instead of `-vvv`. - Enhanced trace output to include labeled contract addresses and decoded function information. [[1]](diffhunk://#diff-4ee92d729fce66f7e7aed1fc29b41834951eb63198e0da747b9b9e45d13f717bL253-R333) [[2]](diffhunk://#diff-4ee92d729fce66f7e7aed1fc29b41834951eb63198e0da747b9b9e45d13f717bR357-R413) ### Dependency and internal updates: * **Dependency additions:** - Added `fuel-core-storage` as a dependency in `Cargo.toml` to support new features. [[1]](diffhunk://#diff-2e9d962a08321605940b5a657135052fbcef87b5e360662bb527c96d9a615542R93) [[2]](diffhunk://#diff-f0f5128eecb15714bd0a80d1f03d87a84f375d0598471bb27e3bb388c188550cR49) * **Parsing and execution logic:** - Refactored `forc-client` to include reusable functions for parsing ABIs and labels. - Updated the `call_function` logic to handle additional ABIs and integrate with the new dry-run execution method. [[1]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeR54-R64) [[2]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeL137-R172) ## 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) - [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). - [ ] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: z <zees-dev@users.noreply.github.com> Co-authored-by: kaya <20915464+kayagokalp@users.noreply.github.com>	2025-06-30 19:14:25 +12:00
zees-dev	5c22e33987	Bump/0.69.0 (#7248) ... ## Description This pull request updates the version of all workspace packages and dependencies from `0.68.9` to `0.69.0` in preparation for a new release. ## 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> Co-authored-by: IGI-111 <igi-111@protonmail.com>	2025-06-23 19:25:04 +04:00
Hannes Karppila	1ac3514f50	Bump fuel deps (#7228) ... ## 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>	2025-06-23 13:05:53 +04:00
Joshua Batty	e054b39628	bump to 0.68.9 (#7247) ... ## Description ~~waiting on #7246 which fixes a critical bug in `forc pkg`~~ ## 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) - [ ] 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>	2025-06-23 16:09:30 +10:00
IGI-111	b9ac2a9bdb	Bump to 0.68.8 (#7235) ... waiting on #7214	2025-06-19 02:35:35 +04:00
Joshua Batty	ac76804198	LSP: Support multiple workspaces (#7214) ... ## Description The langauge server now supports multiple workspaces and individual projects in a single server instance. For example, in the sway repo itself, we have 3 large sway project workspaces. Before this change, LSP would only work for the first workspace you opened. Now you can freely move between projects and workspaces. There is a bit of code quality associated with this PR to better reflect the new approach rather than the contained `Session` type that we had previously. ## Other changes * This PR fixes a bug with `forc-pkg` that would panic if it was called from an async context. i.e `forc-lsp` or `forc-doc`. We now check if a `tokio` runtime exists and use that to avoid crashing in these situations. * Document symbols are now collected for more types. We also check that document symbols are present for all files in the std library as well as semantic tokens during the test. ## 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) - [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: zees-dev <63374656+zees-dev@users.noreply.github.com>	2025-06-18 16:18:26 +04:00
Igor Rončević	134916d5b4	Support ABI errors in forc test (#7224) ... ## Description This PR adds support for ABI errors in `forc test`. If a unit test reverts, the received revert code is inspected for known error signals (e.g., coming from `assert`, or `require`) and for ABI errors. Analysis of the received revert code is encapsulated within the `forc_util::tx_utils::RevertInfo` struct implementation. This way, it can be reused between the `forc test` and `forc call`. However, on the long term, this abstraction should be moved to `fuel-abi-types`, because its whole logic is ABI related, and it should also be shareable with the Rust SDK. The reason for temporary placing it within `forc-util` crate is to get the support for ABI errors in `forc test` in the next Sway release, without the need for a new `fuel-abi-types` release that triggers the circular dependency between Sway and Rust SDK repositories. Additionally, the PR unifies the display of test outputs - logs, debug output, and reverts: - for passing tests, none of the output is shown by default, unless specified on the CLI. - for failing tests, all the output is displayed in the "failures" section. - because the `__dbg` output is not a log, a dedicated `--dbgs` CLI argument is added, for all ecal outputs. - because the output of a revert now shows all available information and not only the revert code, the `--revert-codes` CLI argument is renamed to `--reverts`. Closes #7089. ## 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. - [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.	2025-06-10 06:57:07 +04:00
IGI-111	58bf38ef9c	Bump to 0.68.7 (#7219)	2025-06-04 09:11:55 -03:00
zees-dev	a2f88d041c	feat: forc call tracing (#7196) ... ## Description Resolves https://github.com/FuelLabs/sway/issues/6706 Introduces `forc-call` transaction tracing - for verbosity levels `3+` (`-v=3` or `-vvv`). The tracing primarily utilizes transaction receipts, generating a call tree structure, then rendering this tree to `stdout`. Example usage output: ```sh > forc-call --abi ./demo/demo-caller/out/release/demo-caller-abi.json 9275a76531bce733cfafdbcb6727ea533ebbdc358d685152169b3c4eaa47b965 call_increment_count -vvv ``` <img width="629" alt="image" src="https://github.com/user-attachments/assets/6ad73c2a-a08e-4829-8d46-0b951e9b723b" /> <details> <summary>Output receipts for the trace above</summary> ```json { "receipts": [ { "Call": { "id": "0000000000000000000000000000000000000000000000000000000000000000", "to": "9275a76531bce733cfafdbcb6727ea533ebbdc358d685152169b3c4eaa47b965", "amount": 0, "asset_id": "f8f8b6283d7fa5b672b530cbb84fcccb4ff8dc40f8176ef4544ddb1f1952ad07", "gas": 124116, "param1": 10480, "param2": 10508, "pc": 11928, "is": 11928 } }, { "Call": { "id": "9275a76531bce733cfafdbcb6727ea533ebbdc358d685152169b3c4eaa47b965", "to": "b792b1e233a2c06bccec611711acc3bb61bdcb28f16abdde86d1478ee02f6e42", "amount": 0, "asset_id": "0000000000000000000000000000000000000000000000000000000000000000", "gas": 111500, "param1": 67107840, "param2": 67106816, "pc": 19064, "is": 19064 } }, { "ReturnData": { "id": "b792b1e233a2c06bccec611711acc3bb61bdcb28f16abdde86d1478ee02f6e42", "ptr": 0, "len": 0, "digest": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", "pc": 21004, "is": 19064, "data": [] } }, { "LogData": { "id": "9275a76531bce733cfafdbcb6727ea533ebbdc358d685152169b3c4eaa47b965", "ra": 0, "rb": 10098701174489624218, "ptr": 67104256, "len": 25, "digest": "392232ec5cf9a0ef3c155ad19684907344847572e913a7a374d703fb9c9d8b5d", "pc": 15804, "is": 11928, "data": [ 0, 0, 0, 0, 0, 0, 0, 17, 105, 110, 99, 114, 101, 109, 101, 110, 116, 101, 100, 32, 99, 111, 117, 110, 116 ] } }, { "Call": { "id": "9275a76531bce733cfafdbcb6727ea533ebbdc358d685152169b3c4eaa47b965", "to": "b792b1e233a2c06bccec611711acc3bb61bdcb28f16abdde86d1478ee02f6e42", "amount": 0, "asset_id": "0000000000000000000000000000000000000000000000000000000000000000", "gas": 86284, "param1": 67103232, "param2": 67102208, "pc": 19072, "is": 19072 } }, { "ReturnData": { "id": "b792b1e233a2c06bccec611711acc3bb61bdcb28f16abdde86d1478ee02f6e42", "ptr": 67099904, "len": 8, "digest": "cd04a4754498e06db5a13c5f371f1f04ff6d2470f24aa9bd886540e5dce77f70", "pc": 21352, "is": 19072, "data": [ 0, 0, 0, 0, 0, 0, 0, 2 ] } }, { "LogData": { "id": "9275a76531bce733cfafdbcb6727ea533ebbdc358d685152169b3c4eaa47b965", "ra": 0, "rb": 1515152261580153489, "ptr": 67098880, "len": 8, "digest": "cd04a4754498e06db5a13c5f371f1f04ff6d2470f24aa9bd886540e5dce77f70", "pc": 15976, "is": 11928, "data": [ 0, 0, 0, 0, 0, 0, 0, 2 ] } }, { "LogData": { "id": "9275a76531bce733cfafdbcb6727ea533ebbdc358d685152169b3c4eaa47b965", "ra": 0, "rb": 10098701174489624218, "ptr": 67097856, "len": 12, "digest": "a3d2743e2a3ab241ba31ffc7133a43daabe6a8e624c7edc92410068a3896c871", "pc": 16072, "is": 11928, "data": [ 0, 0, 0, 0, 0, 0, 0, 4, 100, 111, 110, 101 ] } }, { "Call": { "id": "9275a76531bce733cfafdbcb6727ea533ebbdc358d685152169b3c4eaa47b965", "to": "b792b1e233a2c06bccec611711acc3bb61bdcb28f16abdde86d1478ee02f6e42", "amount": 0, "asset_id": "0000000000000000000000000000000000000000000000000000000000000000", "gas": 72699, "param1": 67096832, "param2": 67095808, "pc": 19064, "is": 19064 } }, { "ReturnData": { "id": "b792b1e233a2c06bccec611711acc3bb61bdcb28f16abdde86d1478ee02f6e42", "ptr": 0, "len": 0, "digest": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", "pc": 21004, "is": 19064, "data": [] } }, { "Call": { "id": "9275a76531bce733cfafdbcb6727ea533ebbdc358d685152169b3c4eaa47b965", "to": "b792b1e233a2c06bccec611711acc3bb61bdcb28f16abdde86d1478ee02f6e42", "amount": 0, "asset_id": "0000000000000000000000000000000000000000000000000000000000000000", "gas": 48287, "param1": 67093248, "param2": 67092224, "pc": 19072, "is": 19072 } }, { "ReturnData": { "id": "b792b1e233a2c06bccec611711acc3bb61bdcb28f16abdde86d1478ee02f6e42", "ptr": 67089920, "len": 8, "digest": "d5688a52d55a02ec4aea5ec1eadfffe1c9e0ee6a4ddbe2377f98326d42dfc975", "pc": 21352, "is": 19072, "data": [ 0, 0, 0, 0, 0, 0, 0, 3 ] } }, { "ReturnData": { "id": "9275a76531bce733cfafdbcb6727ea533ebbdc358d685152169b3c4eaa47b965", "ptr": 67088896, "len": 8, "digest": "d5688a52d55a02ec4aea5ec1eadfffe1c9e0ee6a4ddbe2377f98326d42dfc975", "pc": 12608, "is": 11928, "data": [ 0, 0, 0, 0, 0, 0, 0, 3 ] } }, { "Return": { "id": "0000000000000000000000000000000000000000000000000000000000000000", "val": 1, "pc": 10388, "is": 10368 } }, { "ScriptResult": { "result": "Success", "gas_used": 89279 } } ] } ``` </details> --- The tracing is inspired by transaction trace provided by `cast run <tx-hash>` tool from foundry. Example usage/output of `cast run`: <img width="711" alt="image" src="https://github.com/user-attachments/assets/ad403c45-8944-4e26-95c3-a6804ef62fe3" /> --- ## Copilot Description This pull request introduces changes to the `forc-call` CLI, focusing on: - improving ABI handling - error reporting - transaction processing It refactors the `call_function` and `transfer` operations, introduces new structures for ABI management, and enhances the verbosity options for debugging transaction outputs. ### Enhancements to ABI Handling: * Introduced a new `Abi` struct to encapsulate `ProgramABI`, `UnifiedProgramABI`, and a type lookup map, simplifying ABI parsing and usage (`forc-plugins/forc-client/src/op/call/mod.rs`). * Updated `call_function` to use the new `Abi` struct and refactored ABI parsing to improve error handling during contract function calls (`forc-plugins/forc-client/src/op/call/call_function.rs`) [[1]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeL49-R62) [[2]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeL213-R245). ### Improvements in Transaction Processing: * Enhanced the `process_transaction_output` function to include `CallData` for better handling of ABI and contract-related data. Also, added support for printing transaction traces and logs with higher verbosity levels (`forc-plugins/forc-client/src/op/call/mod.rs`). * Refactored receipt handling in `call_function` to include detailed error reporting and optional ABI mappings for debugging (`forc-plugins/forc-client/src/op/call/call_function.rs`). ### Code Simplification and Refactoring: * Removed redundant `ProgramABI` usage in the `transfer` function and updated it to use the new transaction processing logic (`forc-plugins/forc-client/src/op/call/transfer.rs`). * Consolidated imports and removed unused dependencies across multiple files to streamline the codebase (`forc-plugins/forc-client/src/op/call/call_function.rs`, `forc-plugins/forc-client/src/op/call/mod.rs`, `forc-plugins/forc-client/src/op/call/transfer.rs`) [[1]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeL6-R18) [[2]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeL32-R33) [[3]](diffhunk://#diff-6b8144a652cd418525566ff9da96c87495dd239934e78788f2f79422657e5960L2-L8). ### Enhanced Debugging and Verbosity: * Added a new `print_receipts_and_trace` function to format and display transaction receipts and traces based on verbosity levels, aiding in debugging complex transactions (`forc-plugins/forc-client/src/op/call/mod.rs`). * Renamed `script` to `script_json` in `CallResponse` for clarity and consistency with JSON output conventions (`forc-plugins/forc-client/src/op/call/mod.rs`). ## 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. - [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: z <zees-dev@users.noreply.github.com> Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2025-05-30 03:00:17 +00:00
IGI-111	5d8a240cce	Bump to 0.68.6 (#7200)	2025-05-28 13:02:56 +04:00
Igor Rončević	f03d5ecdb0	Compile panic expression to ABI error codes (#7118) ... ## Description This PR is the final step in implementing the `panic` expression and the ABI errors, as defined in the [ABI Errors RFC](https://github.com/FuelLabs/sway-rfcs/blob/master/rfcs/0014-abi-errors.md). The PR generates the `errorCodes` section in the ABI, like, e.g.: ``` "errorCodes": { "18446744069414584320": { "pos": { "pkg": "my_lib@1.2.3", "file": "src/lib.rs", "line": 42, "column": 13 }, "logId": null, "msg": "Error message." }, "18446744069414584321": { "pos": { "pkg": "my_contract", "file": "src/main.rs", "line": 21, "column": 34 }, "logId": "4933727799282657266", "msg": null } } ``` If the `panic` argument is a string slice that can be const-evaluated, the `msg` field of the corresponding error code is generated, and a log is not emitted. The string itself is stored only within the ABI JSON, and is not included into the generated bytecode. Additionally, the PR: - provides a common infrastructure for obtaining a `SourceLocation` from a `Span`. This is currently used in the implementation of the `__dbg` intrinsics and the `panic` expression. - improves filtering of `forc` outputs in snapshot tests by supporting regular expressions. The `grep` command is renamed to `regex` to avoid confusion with piping the actual `grep` CLI command. Partially addresses #6765. ## 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. - [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: hal3e <git@hal3e.io>	2025-05-27 20:32:40 +10:00
BlockyJ	ee565f9145	feat: implement forc add and forc remove to add/remove dependencies (#7143) ... ## Description Close #2369 **Summary:** Implements functionality for `forc` to add remove dependencies through cli, similar to Cargo's `add` and `remove` commands. **Work Done:** * ✅ Added `forc add` command to support adding both regular and contract dependencies from path, git, IPFS, or version. * ✅ Implemented conflict checks for version + source collisions (e.g., version + git). * ✅ Added automatic fallback to workspace-relative path for local packages. * ✅ Introduced `forc remove` to cleanly remove specified dependencies from the manifest. * ✅ Modularized update logic using `DepSection` enum for unified regular/contract dependency handling. * ✅ Used `toml_edit` to update the manifest file while preserving formatting. ## 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. - [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.	2025-05-21 23:47:46 -07:00
Sophie Dankel	512bbfccdb	chore: bump to 0.68.5 (#7185) ... ## Description ## 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.	2025-05-20 08:47:20 -07:00
Sophie Dankel	e3eab78454	feat: use SSE in forc-publish for long-running uploads (#7178) ... This pull request introduces changes to enhance the functionality of the `forc-publish` plugin, including improvements to error handling, support for streaming server responses, and updates to dependencies. The most significant changes include adding a new error variant, updating the `upload` method to handle streaming responses, and modifying dependencies to include `futures-util` and additional features for `reqwest`. ### Enhancements to Error Handling: * Added a new `ServerError` variant to the `Error` enum in `forc-plugins/forc-publish/src/error.rs` to handle server-related errors. ### Improvements to `upload` Method: * Updated the `upload` method in `forc-publish/src/forc_pub_client.rs` to process streaming server responses using `futures-util::StreamExt`. This includes handling chunked data, parsing JSON responses, and printing event updates. [[1]](diffhunk://#diff-c706a808124a73081593a5e34fb999aa1a446f97d97da1657ddb4b3c55d24371R43) [[2]](diffhunk://#diff-c706a808124a73081593a5e34fb999aa1a446f97d97da1657ddb4b3c55d24371L53-R97) ### Dependency Updates: * Added `futures-util` as a dependency in `Cargo.toml` and `forc-plugins/forc-publish/Cargo.toml` to support streaming operations. [[1]](diffhunk://#diff-2e9d962a08321605940b5a657135052fbcef87b5e360662bb527c96d9a615542R157) [[2]](diffhunk://#diff-2bd34a7b1fa0f1850ad25c6e080d410b2df98c16b6cd75445a138d04e617311aL16-R17) * Enabled the `stream` feature for `reqwest` in `forc-plugins/forc-publish/Cargo.toml` to facilitate streaming server responses. ### Minor Adjustments: * Added empty `println!` calls in `main.rs` to improve output formatting during error handling and publishing operations. [[1]](diffhunk://#diff-2c9e261f1e02238f33a9403387f40481b5b372475c0de3782146b614210675b3R32) [[2]](diffhunk://#diff-2c9e261f1e02238f33a9403387f40481b5b372475c0de3782146b614210675b3R52) 	2025-05-20 06:18:57 -07:00
Sophie Dankel	0e3d949dbf	chore: move test deps to dev-dependencies (#7181) ... ## Description I noticed that some test dependencies were being included in builds unnecessarily. This PR moves them to dev-dependencies. ## 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.	2025-05-17 14:26:25 +12:00
Sophie Dankel	1fb61fdc42	chore: bump to v0.68.4 (#7171) ... ## Description ## 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.	2025-05-14 10:29:12 +10:00
Sophie Dankel	48d95fc22e	chore: bump to 0.68.3 (#7167) ... ## Description ## 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.	2025-05-12 21:14:29 -07:00
zees-dev	dffa29c599	feat: forc call json output (#7156) ... ## Description This PR adds JSON output support for `forc-call` CLI. Additionally, it adds JSON support for `tracing-subscriber` in `forc-tracing` - with option to omit logs from other libraries (via regex). - JSON tracing-subscriber ignores colored output - Forc-call hooks into this tracing-subscriber (using `Json` variant) to output JSON response ### Changelog This pull request introduces enhancements to the `forc-call` plugin, focusing on improving output formatting, streamlining verbosity handling, and updating test cases to reflect these changes. The most significant updates include the addition of a JSON output format, the removal of the `Verbosity` struct, and modifications to test cases to handle optional results. ### Output Formatting Enhancements: * Added a new `Json` variant to the `OutputFormat` enum for outputting full tracing information in JSON format. Implemented the `Write` trait for `OutputFormat` to handle different output styles. (`forc-plugins/forc-client/src/cmd/call.rs`, [forc-plugins/forc-client/src/cmd/call.rsR60-R87](diffhunk://#diff-466e2f9659cab303594eb73a846768ecdbc1a13030e5869cdac51ddde87dd313R60-R87)) * Updated the `Command` struct to include a short option (`-o`) for specifying the output format. (`forc-plugins/forc-client/src/cmd/call.rs`, [forc-plugins/forc-client/src/cmd/call.rsL319-R319](diffhunk://#diff-466e2f9659cab303594eb73a846768ecdbc1a13030e5869cdac51ddde87dd313L319-R319)) ### Verbosity Handling Simplification: * Removed the `Verbosity` struct and its associated methods. Verbosity is now directly represented as an integer (`cmd.verbosity`) for simplicity. (`forc-plugins/forc-client/src/cmd/call.rs`, [[1]](diffhunk://#diff-466e2f9659cab303594eb73a846768ecdbc1a13030e5869cdac51ddde87dd313R60-R87); `forc-plugins/forc-client/src/op/call/call_function.rs`, [[2]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeL2-R2) [[3]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeL54-L57) [[4]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeL181-R185) [[5]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeL216-R227) ### Test Case Updates: * Modified test cases to handle optional results by calling `.unwrap()` on the `result` field where applicable. This ensures compatibility with changes to how results are processed. (`forc-plugins/forc-client/src/op/call/call_function.rs`, [[1]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeL356-R387) through [[2]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeL661-R710) These changes improve the usability and maintainability of the `forc-call` plugin, making it more robust and user-friendly. Note: This is a pre-requisite to resolve https://github.com/FuelLabs/sway/issues/7019; the output script in the JSON can be directly parsed into a `tx.json` file for `forc-debug`. ## 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) - [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. --------- Co-authored-by: z <zees-dev@users.noreply.github.com>	2025-05-09 20:07:27 +12:00