287 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
Vaivaswatha N	f92c3f249b	SROA: Do not generate GEPs when direct address is available (#7457) ... Fixes #7433	2025-10-28 12:35:55 +00:00
Igor Rončević	fc2aed7934	Fix build warnings in in-language tests (#7464) ... ## Description This PR fixes warnings emitted in `in-language` tests and sets the `--error-on-warnings` flag when running those tests on CI. This removes unnecessary output, e.g., when extracting performance data (gas usages and bytecode sizes) from the output of the `forc test` runs. Removal of warnings revealed additional DCA issues that are marked as `TODO-DCA` in code and linked to #7462. ## 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. - [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-25 20:10:34 +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
IGI-111	8e44f53775	Stabilize new_hashing (#7437) ... Enable `new_hashing` feature by default whilst still retaining the logic for the old behavior to be removed at a later date. Advances #7256 --------- Co-authored-by: Igor Rončević <ironcev@hotmail.com>	2025-10-03 13:45:13 +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	14bb898f3b	chore: bumpt rust version to 1.90 (#7427) ... ## Description Bumping the rust version to 1.90 and fixing the clippy lints along the way	2025-10-02 22:28:51 +13:00
Mike Christopher	acd13162d5	fix: change runners for publish workflows (#7424) ... ## Description Using larger Actions runners for the GitHub pages and Sway publish steps due to disk size limitations on the standard runners. ## 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. - [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-09-29 14:41:07 +00:00
Mike Christopher	935ffff5cd	fix: migrate to warpbuild and github runner (#7415) ... ## Description Cleans up GitHub actions, migrates Buildjet runners to WarpBuild, and consolidates multiple forc tool checks into a matrix to simplify the `ci.yml` 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. - [ ] 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-09-26 23:30:28 +00:00
zees-dev	cdd8800e75	fix: build-and-release-forc-binaries CI (#7413) ... ## Description Attempt to fix CI using existing action to setup cross. This has been tested to work: 5119897934 ## 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-09-25 06:16:05 -03:00
zees-dev	7d45f82d11	rocksdb compilation error fix (#7408) ... ## Description Attempts to fix error in CI: 5105023518 Build environment setup for RocksDB: * Added a step to install required system packages (`build-essential`, `clang`, `llvm-dev`, `libclang-dev`, `pkg-config`) on Linux runners to support building RocksDB and running `bindgen`. * Configured `LIBCLANG_PATH` and `BINDGEN_EXTRA_CLANG_ARGS` environment variables to ensure `bindgen` can locate the correct Clang libraries and system headers. ## 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>	2025-09-24 07:57:12 -03:00
zees-dev	637db5d5fd	symlink docs dirs for forc-mcp resources for publish CI (#7406) ... ## Description This pull request adds a step to the CI workflow to link the `forc-mcp` documentation into the Cargo target directory. This ensures that the documentation is available in the correct location during the build process. Documentation integration: * Added a CI job step in `.github/workflows/ci.yml` to create a symbolic link for the `forc-mcp` documentation from `docs/book/src/forc/plugins/forc_mcp/forc_call_tool` to `target/docs/book/src/forc/plugins/forc_mcp/forc_call_tool`. ## 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-09-23 14:48:43 +04:00
IGI-111	e8b4fda1fd	Add wasm32 target to publish step (#7405)	2025-09-23 03:52:31 +04:00
Joshua Batty	79f7c60327	Update nightly toolchain for cargo-udeps CI job (#7400) ... ## Description Point `cargo-unused-deps-check` at `nightly-2025-08-15`, which ships rustc 1.88 so `cargo-udeps` and its cargo dependencies install cleanly. This should fix the currently [failing](5090928962) job. ## 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-09-22 12:03:02 +01:00
zees-dev	608fc526ad	gh-pages workflow update to remove archived actions-rs (#7380) ... ## Description Updated the `github pages` workflow; switch from `actions-rs/toolchain@v1` to `dtolnay/rust-toolchain@master` for rust env setup. Also added the `wasm32-unknown-unknown` target. Completely removed `actions-rs` actions - since these are now archived. Inlined the `actions-rs/cargo@v1` to `cargo install` - since the toolchain/binary is available via `dtolnay/rust-toolchain` action. ## 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>	2025-09-10 23:33:55 -07:00
Joshua Batty	4552c75917	forc-doc: Preserve all doc links when merging parallel results (#7379) ... ## Description The sway-lib-std docs are broken and not showing all of the generated documentaiton. The root `index.html` was showing only one module while `all.html` listed only a subset of types. This started happening after the parallel processing was introduced in #7296. This PR fixes this as can be seen in the screenshots below. Also undoes the CI changes in #7362 & #7365 as they aren't necessary as this was the root cause. - Root cause: Using BTreeMap::extend to merge per-item results overwrote existing per-category vectors, so only the last chunk from parallel processing survived. - Fix: replace `.extend` merges with per-key append-and-dedup loops. Before: <img width="1608" height="1040" alt="before" src="https://github.com/user-attachments/assets/e433fcc2-cce6-4737-8ed3-c9e2a679de5a" /> After: <img width="1608" height="1040" alt="after" src="https://github.com/user-attachments/assets/c9e9c007-df6a-49b3-b864-e30d19f487f2" /> ## 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-09-11 04:12:48 +00: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
Joshua Batty	1e04b80c3a	fix: move std library assets into docs directory to fix GitHub Pages deployment (#7365) ... ## Description PR #7362 attempted to fix the std library documentation deployment but broke it completely - the site now shows a 404 error at https://fuellabs.github.io/sway/master/std/. The issue was that CSS and JavaScript assets (`static.files/`, `search.js`) were not being deployed, causing the documentation to be unusable even when HTML pages loaded. This fix: 1. Builds docs with `forc doc` 2. Moves `static.files/` and `search.js` into the `std/` directory 3. Updates HTML relative paths (removes `../` references) 4. Deploys the complete package to `master/std` ## 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-09-02 15:29:21 -07:00
Joshua Batty	0aef56aa59	fix: correct GitHub Pages deployment path for std library docs (#7362) ... ## Description The GitHub Pages deployment for the Sway standard library documentation was pointing to the wrong directory, causing only partial content to be deployed to https://fuellabs.github.io/sway/master/std/. `.github/workflows/gh-pages.yml` was deploying from `./sway-lib-std/out/doc` but the actual documentation files are generated in `./sway-lib-std/out/doc/std/`. This path mismatch resulted in incomplete documentation deployment. ## 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-08-30 09:54:20 -07:00
Igor Rončević	9899de0ca9	Remove cargo-run-e2e-test-evm job from CI (#7349) ... ## Description This PR removes the `cargo-run-e2e-test-evm` from the CI. We currently do not support EVM and running the tests only slows the CI down by re-running the tests that are not EVM dependent like, e.g., language tests that fail compiling programs, or snapshot tests that anyhow do not run with the EVM target. All those tests are already tested for FuelVM in both `debug` and `release` mode. ## 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-08-26 12:26:16 +12: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
Igor Rončević	8d4178f12d	Implement new hashing (#7259) ... ## Description This PR implements new hashing, as explained in the tracking issue #7256. New hashing is an opt-in experimental feature with the feature flag `new_hashing`. The new hashing hashes lengths as prefix to the content hash for the following built-in and `std` types: - string slices (`str`) - arrays (`[T; N]`) - `std::vec::Vec<T>` - `std::bytes::Bytes` Some of the `std` types that use the above types internally for storing their content still hash only the content, without the length prefix of the container. The reason for this is that 1) the choice of the container is just an implementation detail and 2) the semantics of the type requires only the content (mostly of the fixed, type-specific length) to be hashed. A typical example would be `std::b512::B512` where, same to `b256` we want to hash only the content. Notice that this does not cause the security issue described in #7256. Here is the complete list of those types: - `std::crypto::secp256k1::Secp256k1` - `std::crypto::secp256r1::Secp256r1` - `std::crypto::message::Message` - `std::crypto::public_key::PublicKey` - `std::b512::B512` Some of the implementations differ based on the combination of `const_generics` and `new_hashing` features. Therefore, on CI, we have a step testing both experimental features together. Additionally, the PR: - adds missing `Hash` implementations for string arrays (`str[N]`). - adds testing of `const_generics` experimental feature to CI. ## 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. - [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-07-11 14:39:29 +12: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
Joshua Batty	c37dc92952	remove archived forc-explore plugin from CI and docs (#7257) ... ## Description This repo was [archived ](https://github.com/FuelLabs/forc-explorer )in July 2024 but was not removed from CI or the docs. I have update the plugins section of the documentation from forc explore to `forc-install` which is a [tool](https://github.com/DarthBenro008/forc-install) from a community member. ## Checklist - [x] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-06-27 12:53:25 +00:00
IGI-111	5064247397	Stabilize ABI errors (#7241) ... ## Description Stabilize the `error_type` feature. Fixes #6765 ## 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: Igor Rončević <ironcev@hotmail.com>	2025-06-23 10:37:35 +00:00
kaya	128f9c7fbd	fix: add forc-call to binary stripping step in ci (#7237) ... ## Description Fixes ci to add `forc-call` to list of binaries we strip and add to the final binary pack. This should fix the issue of missing forc-call in latest (while having it in nightly as [sway-nightlies](https://github.com/FuelLabs/sway-nightly-binaries/releases) already includes `forc-call`)	2025-06-18 00:41:38 +00:00
Joshua Batty	e0b57e94ba	Remove Docker jobs from CI (#7221) ... ## Description Just spoke with Jibril and Brandon. There hasn't been a single download of the docker images in years. [see here](https://github.com/FuelLabs/sway/pkgs/container/forc/versions?page=1). Removing these jobs to save on CI time since they aren't being used by anyone. ## 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-05 09:26:42 +04:00
Dmytro Medynskyi	5a95c65b61	ci: install Forc plugins by iterating the plugins in the forc-plugins directory (#7183) ... Closes #7169 ## Description This PR replaces manual forc-plugins installation with `for loop` over directories inside `forc-plugins` on CI. Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>	2025-05-20 23:39:50 +00:00
Sophie Dankel	be7a9698b1	ci: release sway std after publishing forc binaries (#7170) ... ## Description The forc.pub server, invoked from `forc-publish` tries to use the same version of forc to build the project as the `forc-publish` version. This means we should wait until the new forc binary is published before invoking `forc-publish`. ## 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-13 13:19:47 -07:00
Igor Rončević	68e0423e15	Run forc-unit-tests on CI in release and debug mode (#7159) ... ## Description This PR: - changes the configuration of Forc and Forc plugins used in CI steps from `debug` to `release`. - changes the `forc-unit-tests` CI step, to run the tests both in `debug` and `release` mode. By switching to `release` builds, we ensure that we test the versions that are actually released, unlike the `debug` version. As a consequence, execution time of CI steps gets shortened. The drawback is potentially not catching issues detectable only in the `debug` mode, like, e.g., overflows. We will add a separate CI workflow, running nightly or on tagged versions only, that will use `debug` builds as explained in #7168. Currently, we are running `forc-unit-tests` only in the `debug` mode. Compiler panics in `in_language_tests`, described in #7157, that happens only in `release` mode, shows that it is beneficial to run the unit test both in `debug` and `release` mode. Similar is with compiler panics described in #7161. The PR also removes the explicit `forc build` part from those tests and leaves only the `forc test` part. The reasoning behind that change is, that `forc test` also builds the projects, indeed with tests included, but, since we currently don't support `#[cfg(test)]`, otherwise unchanged. Running `forc build` in addition effectively doubles the test execution time, and the actual benefit in testing, compared to running only `forc test` is, in best case, negligible. ## 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. - [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: Sophie Dankel <47993817+sdankel@users.noreply.github.com>	2025-05-13 14:08:53 +04:00
Sophie Dankel	078c50738f	ci: publish lib-std on release (#7165) ... ## Description Related https://github.com/FuelLabs/sway/issues/7040 Publish sway `std` library to https://forc.pub/ when a release is created. ## 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 12:55:33 +04:00
Sophie Dankel	a37e3cdc99	ci: Ensure that std-lib version matches forc version (#7154) ... ## Description Sway `std` library will be released when `forc` is released. To keep it simple, we'll ensure that the version of sway `std` matches the version of `forc`. This PR adds a CI step to enforce this. ## 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-08 08:12:35 +04:00
Sophie Dankel	7206479528	Add forc-publish to release binaries (#7129) ... ## 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. --------- Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2025-04-30 00:55:36 +00:00
Luiz Estácio | stacio.eth	84f9c676ba	chore: update codeowners from swayex to onchain team (#7128) ... This pull request updates the `.github/CODEOWNERS` file to reflect changes in team ownership for specific directories. The most notable changes involve replacing `@FuelLabs/swayex` with `@FuelLabs/onchain` for several directory assignments. Ownership updates: * [`/docs/`](diffhunk://#diff-3d36a1bf06148bc6ba1ce2ed3d19de32ea708d955fed212c0d27c536f0bd4da7L5-R9): Replaced `@FuelLabs/swayex` with `@FuelLabs/onchain` as one of the assigned teams. * `/examples/` and `/sway-lib-std/`: Similarly replaced `@FuelLabs/swayex` with `@FuelLabs/onchain` for these directories. Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2025-04-30 00:25:05 +00:00
João Matos	173b65b335	Upgrade CI and fix Clippy issues with Rust 1.86.0 (#7127) ... ## Description As title says. --------- Co-authored-by: IGI-111 <igi-111@protonmail.com>	2025-04-29 12:04:03 +00:00
kaya	760a2bfc7b	chore: bump fuel-core to 0.43.1 and fuels to 0.72 (#7110) ... ## Description Dependency bump to get fuels 0.72 and fuel-core 0.43.1 support. --------- Co-authored-by: bitzoic <bitzoic.eth@gmail.com>	2025-04-24 13:50:40 +10:00
Joshua Batty	a5af067f55	fix(ci): update Docker actions to fix GitHub cache deprecation error (#7104) ... ## Description This PR fixes the CI pipeline failures caused by GitHub's deprecation of their legacy caching service. ## Problem Our CI was failing with the error: ``` ERROR: This legacy service is shutting down, effective April 15, 2025. Migrate to the new service ASAP. For more information: https://gh.io/gha-cache-sunset ``` This was caused by our use of `docker/build-push-action@v2` which relies on the legacy GitHub Actions caching service that's being deprecated. ## Changes * Updated docker/build-push-action from v2 to v6 to use the new caching service * Updated related Docker actions for compatibility * docker/metadata-action from v3 to v5 * docker/setup-buildx-action from v1 to v3 * docker/login-action from v1 to v3 * Merged changes from external contributor to update actions/checkout from v3 to v4 for Node 20 compatibility supersedes #7098 ## 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-04-23 04:48:32 +00:00
kaya	6bc4b06760	ci: move build binaries step to ubuntu-22.04 (#7099) ... ## Description `build-and-release-forc-binaries` step failed in the last release because it was using an old OS version (20.04). The details can be seen [here](4097538193) and [here](https://github.com/actions/runner-images/issues/11101).	2025-04-22 17:49:50 -07:00
kaya	a926cfb7b9	ci: add a step to reject x.y.z versioning for dependencies (#7082) ... ## Description closes #7035. Adds a CI step to ensure we do not introduce x.y.z versions in the `Cargo.toml`. For fuel-core-client we enforce the version to be in form x.y.z. For some pre-defined set we allow either x.y.z and x.y (`etk-asm`, `etk-ops`, `dap`) and for the rest we enforce that the versions are in the form of x.y	2025-04-14 00:49:07 +00:00
kaya	b59e1b627d	ci: include forc-node binaries in releases (#7069) ... Adds forc-node binary (introduced in #6473 ) to the sway repo releases.	2025-04-08 11:31:10 +12:00
Brandon Kite	f6a4cf657a	move codspeed benchmarks to buildjet (#7062) ... ## Description The default ubuntu runners are too limited to run the codspeed benchmarks, this PR moves the benchmarks over to buildjet	2025-04-04 02:12:03 +00:00
Igor Rončević	58114d7e68	Promote experimental features (#7016) ... ## Description This PR promotes the following experimental features to standard ones: - #6701 - #6883 - #6994 - #7006 Additionally, the PR stenghtens the migration infrastructure by checking some additional cases in selecting corresponding typed elements in desugared code which were not checked before. Closes #6701. Closes #6883. Closes #6994. Closes #7006. ## 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. - [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-03-13 20:47:01 +11:00
SwayStar123	a5d9d2835f	Merge std and core libraries (#6729) ... ## Description Merges the two libraries. They were initially separate to separate the core logic and fuel vm specific functionality, but that separation is no longer maintained so having a merged library is better. Closes #6708 ## 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: Sophie <47993817+sdankel@users.noreply.github.com> Co-authored-by: Igor Rončević <ironcev@hotmail.com>	2025-03-12 23:52:38 +01:00
Daniel Frederico Lins Leite	52de221e87	fix fallback compilation on new encoding (#6998) ... ## Description When running tests in contracts with the fallback function, we get an error with the `__log` intrinsic. The issue is that we needlessly compile the fallback function twice. And in some cases (numeric decay), the `__log` argument would return a `TypeId` that was not collected in the `collect_metadata` phase. ``` 29 | 30 | use std::call_frames::*; 31 | __log(3); | ^^^^^^^^ Internal compiler error: Unable to determine ID for log instance. Please file an issue on the repository and include the code that triggered this error. 32 | __log(called_method()); 33 | __log("double_value"); | ____ ``` This was never caught because we only compile `sdk-harness` tests, we never run their unit tests in the CI. Which this PR is also doing. ## 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) - [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-03-11 15:58:01 +00:00
Cameron Carstens	be5ecbd692	Implement TryFrom<Bytes> for b256 (#6958) ... ## Description `impl From<Bytes> for b256` has been removed and replaced with `impl TryFrom<Bytes> for b256` increasing saftey when converting between the two types. `impl Into<Bytes> for b256` and `impl TryInto<b256> for Bytes` have also been added. This PR breaks the following implementation: ```sway let mut my_bytes = Bytes::new(); my_bytes.push(1u8); let result: b256 = b256::from(my_bytes); ``` The implementation should now be: ```sway let mut my_bytes = Bytes::new(); my_bytes.push(1u8); // Option 1 let result_1: Option<b256> = b256::try_from(my_bytes); // Option 2 let result_2 = my_bytes.try_into(); ``` Closes #6994. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: Igor Rončević <ironcev@hotmail.com>	2025-03-05 17:20:13 +04:00
Sophie Dankel	ba7c4a9297	ci: upgrade to rust 1.85.0 (#6979) ... ## 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-03-04 11:28:22 +04:00
IGI-111	ccba9b13bf	Update mdbook to 0.4.45 in CI (#6973) ... Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>	2025-03-04 00:27:03 +00:00
Sophie Dankel	f2ab717fa9	ci: Install forc-node in gh-pages.yml (#6978) ... ## Description Unblock 3809258034 ## 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-03-03 16:05:01 -08:00
Kaya Gökalp	15899514eb	feat: add forc-node command for easily bootstrapping a node (#6473)	2025-02-15 12:34:45 +11:00