547 commits

Author	SHA1	Message	Date
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ć	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
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
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	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
Vaivaswatha N	36d2b12eb1	Skip returning a value when the type is unit (#7401) ... https://github.com/FuelLabs/sway/pull/7381#discussion_r2358242393	2025-09-24 12:22:32 +10:00
Vaivaswatha N	df6839d966	When demoting aggregate returns, no need to return back the new argument pointer (#7381) ... This aids optimizations to perform better. For example https://github.com/IGI-111/blackjack comes down from `22.288 KB` to `21.312 KB`.	2025-09-22 10:10:13 +10:00
Vaivaswatha N	d49cf8e92c	compile string constants to global rather than local memory (#7359) ... In situations such as in the newly added test (taken from the fuels-rs repo), without this change, we end up returning a pointer to local memory.	2025-08-28 20:21:14 +05:30
Igor Rončević	9e98c0e9f6	Apply Clippy's uninlined_format_args lint (#7361) ... ## Description This PR improves the readability of `format!`, `write!`, etc. macros by rolling out the Clippy fixes for the `uninlined_format_args` lint. `cargo clippy` started showing this lint after locally switching to Cargo v1.88.0. Additionally, the PR: - replaces a few occurrences of `io::Error::new(std::io::ErrorKind::Other, <msg>)` with `io::Error::other(<msg>)`. - replaces a single occurrence of `if params.iter().any(|&p| p == "all")` with `if params.contains(&"all")`. ## 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-27 21:57:48 -03:00
João Matos	8be2dae76b	Implement a command to dump impls for a given type (#7322) ... This adds a new `--dump-impls` CLI command that can be used to dump all the recognized trait impls for a given type name. This also extends the compiler diagnostic system to allow the emission of info diagnostics, as previously we could only emit either warnings of errors, which did not fit this use case. ## Description For example, here is the output of `cargo run --bin forc -- build --path _test-case --dump-impls=std::string::String`: <img width="677" height="958" alt="image" src="https://github.com/user-attachments/assets/42aeca94-bbf9-4dff-8bb3-d1a70000999a" /> And for enums: <img width="642" height="285" alt="image" src="https://github.com/user-attachments/assets/ac565fea-9ebe-4f1d-a9a8-d022617d23d0" /> Closes https://github.com/FuelLabs/sway/issues/7286. ## 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-08-26 16:02:16 -07:00
Vaivaswatha N	05e667dfc9	Remove some uses of ptr_to_int and int_to_ptr, using ptr instead (#7297) ... This is in preparation for the argument mutability analysis. This PR also has some skeleton code for this analysis, but the actual analysis is still a `todo!()`. The analysis will also have better precision if we use fewer asm blocks, but I'll get to that after working on the analysis itself.	2025-08-01 19:22:59 +10:00
Vaivaswatha N	a5e61488da	Represent RawUntypedPtr AST type using a new Pointer IR type (#7272) ... The existing `Pointer` IR type is renamed to `TypedPointer` (to be consistent with the existing `Slice` / `TypedSlice` IR types).	2025-07-22 04:26:38 +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
Hannes Karppila	74092cbbcd	Subroutine calls using the new JAL instruction (#7085) ... ## Description This PR contains an initial implementtion of subroutine calls using the in-progress [jump-and-link instruction `JAL`](https://github.com/FuelLabs/fuel-specs/pull/630). It substantially reduces the function call overhead: the old code used 4 instructions per call, while the new version uses 1-3 depending on the distance to the called function. ### Future optimizations * Reorder functions, so those that call each other are adjacent * Use absolute or IS-relative jumps where it makes sense, see https://github.com/FuelLabs/sway/issues/7267 ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] 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-12 08:23:53 +00:00
Vaivaswatha N	0cae7a3195	treat string array values as if it were [u8; N] (#7258) ... The goal of this PR is to enable the check in the IR verifier to ensure that the operand to `ptr_to_int` instructions can only be pointers. The other changes are to support that.	2025-06-30 19:58:29 +05:30
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
Vaivaswatha N	776c6cf474	minor adjustment to inliner heuristic (#7232) ... This change reduces the generated code size on our `should_pass` testsuite. Numbers are attached. [should_pass_master.txt](https://github.com/user-attachments/files/20754502/should_pass_master.txt) [should_pass_inliner.txt](https://github.com/user-attachments/files/20754501/should_pass_inliner.txt) --------- Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2025-06-23 06:17:05 +05:30
Vaivaswatha N	e0724422c6	IR: Taking function arg address and representing references as pointers (#6967) ... ## Description This is the third PR to address #6351. It allows safely taking addresses of function arguments, and represents references (`&`) as pointers in the IR. Note: The entire function `type_correction` (in `ir_generation.rs`) and this [edit](2de7ab9ec1 (diff-3b0502f41aeb3c45ddbdb3cc590658d73d2bd7283671eb6d789d7e77a7dd2596R670)) in `compile.rs`, to handle return values, must be removed once we fix and finalize the syntax of references. Until then these two hacks need to stay. Ideally I wanted to put them both in one place (which is the `type_correction` pass), but the return type fix needs to happen, unfortunately, during IR gen. --------- Co-authored-by: IGI-111 <igi-111@protonmail.com> Co-authored-by: Igor Rončević <ironcev@hotmail.com>	2025-06-13 10:12:28 +10: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
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
Igor Rončević	7386b19846	Remove double IR-compilation of contract methods (#7164) ... ## Description This PR removes the double compilation of contract methods in the IR, in the case of new encoding. The contract methods were first compiled as a part of the compilation of the `__entry` function, and afterwards, again separately. The contract methods compiled in the second compilation pass were later on removed as not reachable. The issue was brought to the surface in a test written by @hal3e in [fuel-rs PR that integrates ABI errors](https://github.com/FuelLabs/fuels-rs/pull/1651). In that particular test, because of the double compilation, a `panic` expression in a contract method got compiled twice and produced two same entries in the ABI JSON. Removing the double compilation resulted in a small reduction of bytecode size and gas usage. In some tests bytecode size got reduced for ~50 bytes and the gas usage for ~30 gas units. Additionally, the PR adjusts the printing of IR global variables, to be the same as printing of configurables and locals, without the spaces between individual entries. ## 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-05-12 16:52:58 +00:00
Hannes Karppila	1c885cf0f1	codegen optimization: symbolic fuel-vm interpretation (#7109) ... ## Description This PR adds an initial support to symbolic fuel-vm interpretation to improve codegen. The symbolic execution is designed to be extended in later PRs. In it's current form, it provides three distinct improvements: 1. If a temporary (allocated) register contains a value already held in another register, we can use that other register instead. This reduces register pressure, and removes unnecessary `mov` ops. 2. If a register already has the value we're setting it to, we can eliminate the instruction doing so. 3. For conditional jump instructions, if the value of the condition is known, one of the branches can be elminated. In such cases, the instruction is either removed or replaced with an unconditional jump. Dead code elimination pass can then potentially remove the now-unreachable branch. In addition to these changes, this PR takes the optimization level into account for asm generation. For debug builds, we only run the optimization passes once. But for release builds we run the optimization passes multiple times, until we either cannot eliminate any more operations, or until a fixed upper limit of rounds. For instance, this means that if the new pass added in this PR manages to eliminate a branch, and then dead code elimination removes that code, it could allow the interpretation pass to do even more work. To account for new optimization passes, I also organized them to mulple files, so that the ones which create private types are scoped well and thus easier to read. ## Impact project | size before | size after | size reduction -|-|-|- mira-v1-core | 89.384 KB | 83.480 KB | 6.6% ## 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). No changes required! - [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. Just updated pre-existing ones! - [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: Vaivaswatha N <vaivaswatha.nagaraj@fuel.sh> Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2025-05-05 10:50:08 +03:00
Igor Rončević	5f64b96f9c	Implement panic expression (#7073) ... ## Description This PR introduces the `panic` expression to the language, as defined in the [ABI Errors RFC](https://github.com/FuelLabs/sway-rfcs/blob/master/rfcs/0014-abi-errors.md#panic). The `panic` expression can be used without arguments, or accept an argument that implements the `std::marker::Error` trait. The `Error` trait is implemented by the compiler for the unit `()`, string slices, and `#[error_type]` enums. Using the `panic` expression without arguments gives the symetry with the `return` expression and acts in the same way as having unit as an argument. ``` panic; panic (); panic "This is some error."; panic Errors::SomeError(42); ``` Panicking without an argument or with unit as argument is discouraged to use. In the upcoming PR that finalizes the ABI errors feature, we will emit a warning if the `panic` is used without arguments or with unit as argument. `panic` expression is available in all program kinds. In predicates it currently compiles only to revert. Once `__dbg` intrinsic is implemented, we can consider compiling to it in predicates. In the upcoming PR, the `error_codes` entry in the ABI JSON will be available for all program kinds. The dead code analysis for the `panic` expression is implemented in the straightforward way, following the current approach of connecting reverts to the exit node. This will be revisted in a separate PR, together with the open TODOs in the DCA implementation of `Return`. Essentially, we want reverting/panicking to connect to program exit and implicit returns to the exit node. Additionally, the PR: - extends `forc test` CLI attributes with `--revert-codes` that prints revert codes even if tests are successful but revert. - updates outdated "Logs Inside Tests" chapter in the documentation on unit testing. - extends the snapshot testing infrastructure to support `forc test` in snapshot tests. - fixes #7072. Partially addresses #6765. ## Breaking Change `panic` is a new reserved keyword. Once the `error_type` feature becomes integrated, compiling any existing code containing a "panic" as an identifier will result in an "Identifiers cannot be a reserved keyword." error. In this PR, `panic` keyword is hidden behind the `error_type` feature flag. This prevents existing code from breaking, unless opted-in. Note that, although being behind a feature flag, `panic` cannot be used in conditional compilation, means in combination with the `#[cfg(experimental_error_type = true/false)]`. The reason is that `cfg` evaluation happens after parsing, and we can either parse `panic` as a keyword or identifier during the parsing, because we cannot distinguish ambiguous cases like `panic;` or just `panic`. This limitation means, that introducing `panic` to `std` can be done only once the `error_type` feature is fully integrated. In practice, this is not a serious limitation, because introducing `panic` in `std` would anyhow, due to effort and design decisions, happen after the feature is integrated. We will provide a migration for this breaking change that will migrate the existing "panic" identifiers to "r#panic". ## 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-04-30 20:07:05 +10:00
Daniel Frederico Lins Leite	f736fce7ac	Debug trait and its auto implementation (#7015) ... ## Description This PR implements the `__dbg(...)` intrinsic, which is very similar to Rust `dbg!(...)` macro. Up until now, it has being the norm to use `__log` to debug values. Given that this is NOT the first use case for log, we have always found some issues with it: log does not work on predicates, log does not show "private" fields like `Vec::capacity` and others. To solve these problems `__dbg` is being introduced: 1 - it will work on all program types, including predicates; 2 - it also prints the file name, line and column; 3 - All types will have an automatic implementation of Debug if possible, which can still be customized. 4 - Even `raw_ptr` and other non "loggable" types, have `Debug` impls. 5 - `__dbg` will be completely stripped in the release build by default. It can be turned on again if needed. So this: ``` // Aggregates let _ = __dbg((1u64, 2u64)); let _ = __dbg([1u64, 2u64]); // Structs and Enums let _ = __dbg(S { }); let _ = __dbg(E::None); let _ = __dbg(E::Some(S { })); ``` will generate this: ``` [src/main.sw:19:13] = (1, 2) [src/main.sw:20:13] = [1, 2] [src/main.sw:23:13] = S { } [src/main.sw:24:13] = None [src/main.sw:25:13] = E(S { }) ``` How does this work? `__dbg(value)` intrinsic is desugared into `{ let f = Formatter{}; f.print_str(...); let value = value; value.fmt(f); value }`. `Formatter` is similar to Rust's one. The difference is that we still do not support string formatting, so the `Formatter` has a lot of `print_*` functions. And each `print` function calls a "syscall". This `syscall` uses `ecal` under the hood and it follows unix write syscall schema. ```sway // ssize_t write(int fd, const void buf[.count], size_t count); fn syscall_write(fd: u64, buf: raw_ptr, count: u64) { asm(id: 1000, fd: fd, buf: buf, count: count) { ecal id fd buf count; } } ``` For that to work, the VM interpreter must have its `EcalState` setup and interpret syscall number 1000 as `write`. This PR does this for `forc test` and our `e2e test suite`. Each test in `forc test` will capture these calls and only print to the terminal when requested with the `--log` flag. ## Garbage Collector and auto generated Before, we were associating all auto-generated code with a pseudo file called "&lt;autogenerated&gt;.sw" that was never garbage collected. This generated a problem inside the LSP when the `auto_impl.rs` ran a second time because of a collision in the "shareable type" map. When we try to solve this collision, choosing to keep the old value or to insert the new, the type inside the map points to already collected types and the compiler panics. This is a known problem. The workaround for this is to break the auto-generated code into multiple files. Now they are named "main.autogenerated.sw", for example. We create one pseudo-file for each real file that needs one. When we garbage collect one file, `main.sw`, for example, we also collect its associated auto-generated file. ## 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. - [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-04-22 07:49:31 -03:00
Daniel Frederico Lins Leite	f607a674e3	More Sway compiler optimizations (#7093) ... ## Description This PR is a prequel to https://github.com/FuelLabs/sway/pull/7015, trying to optimize the compiler to alleviate the hit of having more items, `impl` etc... We have here two optimizations: 1 - We spend a lot of time counting newlines when converting byte offsets to `LineCol`. Now, we calculate line offsets just once, and use binary search later to find which line a byte offset is at. 2 - `QueryEngine::get_programs_cache_entry` was cloning the whole `TyProgram`. That is why `did_change_with_caching` was always getting worse, as the program was increasing in size. Now all compilation stages are behind `Arc`, which makes the `clone` free. ## Analysis Putting a `dbg!(...)` like the image below, and calling `counts` (https://github.com/nnethercote/counts). ``` cargo bench -- traverse 2>&1 | grep "sway-types/src/span.rs:29:9" | counts ```  I get the following results: ``` 972102 counts ( 1) 156720 (16.1%, 16.1%): [sway-types/src/span.rs:29:9] self.pos = 0 ( 2) 15900 ( 1.6%, 17.8%): [sway-types/src/span.rs:29:9] self.pos = 104 ( 3) 15840 ( 1.6%, 19.4%): [sway-types/src/span.rs:29:9] self.pos = 107 ( 4) 2280 ( 0.2%, 19.6%): [sway-types/src/span.rs:29:9] self.pos = 19281 ( 5) 2280 ( 0.2%, 19.9%): [sway-types/src/span.rs:29:9] self.pos = 19285 ( 6) 2280 ( 0.2%, 20.1%): [sway-types/src/span.rs:29:9] self.pos = 19287 ( 7) 2280 ( 0.2%, 20.3%): [sway-types/src/span.rs:29:9] self.pos = 19292 ( 8) 2280 ( 0.2%, 20.6%): [sway-types/src/span.rs:29:9] self.pos = 19323 ( 9) 2280 ( 0.2%, 20.8%): [sway-types/src/span.rs:29:9] self.pos = 19327 ( 10) 2280 ( 0.2%, 21.0%): [sway-types/src/span.rs:29:9] self.pos = 19329 ( 11) 2280 ( 0.2%, 21.3%): [sway-types/src/span.rs:29:9] self.pos = 19334 ( 12) 870 ( 0.1%, 21.4%): [sway-types/src/span.rs:29:9] self.pos = 4285 ... ``` This means that `line_col` is being called 972k times. 16% is for position zero, which should be trivial. The rest will iterate the whole file source code to count number of lines. Making the real complexity of the work here something like `O(qty * self.pos)`. And some values of `self.pos` are not trivial at all. ## 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-21 12:36:15 -07:00
kaya	ba3a0d5635	feat: registry source resolution and builds (#7038) ... ## Description closes #3752, #6903. Adds registry source resolutions and support for building.	2025-04-09 21:09:47 -07:00
BlockyJ	1c68f1c9e0	Add --generate-hexfile flag to forc build for hex-encoded output (#7032) ... close #5017 PR adds new `--generate-hexfile` flag to the `forc build` command, enabling it to output a hex-encoded JSON representation of the compiled binary alongside the `.bin` file. #### ✅ Changes - Added `--generate-hexfile` flag to `forc build`. - Outputs a `.json` file containing the hex-encoded script binary (e.g., `contract-hex.json`). - Ensures bundler compatibility for frontend/SDK consumption. #### 🧪 Example Output ```json { "hex": "0xdeadbeefcafebabe..." } ``` #### 📦 Example Usage ```bash forc build --generate-hexfile ``` Generates: - `contract.bin` (as before) - `contract-hex.json` (new hex representation) ## 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. --------- Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com> Co-authored-by: zees-dev <63374656+zees-dev@users.noreply.github.com> Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2025-04-08 12:13:13 +00: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
zees-dev	20973803db	forc-call logs support (#6968) ... ## Description - Added support for viewing emitted logs when making a transaction using forc-call - Added `show_receipts` param (default-false) - so we can optionally prnt out all receipts - The CLI output becomes too long for a call with multiple receipts; this is a minor UI enhancement Addresses https://github.com/FuelLabs/sway/issues/6887 ## Example usage/output ```sway script; struct ExampleParams { test_val: u32, test_str: str, test_tuple: (u32, u64), } fn main() -> u64 { log("hiiii"); log(123); log(ExampleParams { test_val: 5, test_str: "hello world", test_tuple: (1,2) }); 5 } ``` <img width="986" alt="image" src="https://github.com/user-attachments/assets/3725ff17-29c9-43d7-98cc-4cacfc213ecb" /> ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] 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: kayagokalp <kayagokalp123@gmail.com>	2025-03-01 14:26:16 +13:00
Sophie Dankel	597ecfb6e0	chore: move dev dependencies to workspace (#6966) ... ## Description Moves dev dependencies to the workspace Cargo.toml for consistent versions in tests. Inspired by https://github.com/FuelLabs/sway/pull/6955 ## 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-02-28 11:44:11 +11:00
Hannes Karppila	37235f2e7d	codegen: Use idiomatic fuel-vm ops for memcpy and addr_of (#6795) ... ## Description SIgnificantly reduces bytecode sizes by transforming the following commonly-used operations when the constant value fits into the immediate part of the `*i` variant of the instruction: * `MOVI(tmp, copy_len); MCP(dst, src, tmp)` → `MCPI(dst, src, copy_len)` (in `compile_mem_copy_bytes`) * `MOVI(dst, offset); ADD(dst, dst, DATA_SECTION)` → `ADDI(dst, DATA_SECTION, offset)` (in `addr_of`) ## Checklist - [ ] I have linked to any relevant issues. (none that I know of) - [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). (no changes required) - [ ] 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. (partially; some values in tests got smaller. we don't seem to be tracking the size and size regressions in tests) - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. (not 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-01-16 10:49:25 +11:00
Sophie Dankel	6245ee6018	feat: add function for generating bytecode identifier (#6674) ... ## Description Depends on https://github.com/FuelLabs/sway/pull/6522 Related https://github.com/FuelLabs/forc.pub/issues/16 Adds a function, `get_bytecode_id` that generates a sha256 hash of the bytecode with the configurables section of the bytecode removed. This will be used for indexing and lookups of the corresponding ABIs for contracts, predicates, and scripts in the package registry (forc.pub). ## 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: Vaivaswatha Nagaraj <vaivaswatha.nagaraj@fuel.sh> Co-authored-by: IGI-111 <igi-111@protonmail.com> Co-authored-by: Marcos Henrich <marcoshenrich@gmail.com> Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2024-11-19 08:49:41 -08:00
Vaivaswatha N	9741809659	Add configurables section offset in the preamble (#6709) ... Re-enabling this feature after a bugfix. (reverted PR: #6522) --------- Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com> Co-authored-by: IGI-111 <igi-111@protonmail.com>	2024-11-18 12:33:47 +05:30
João Matos	6e31144e2b	Profiling support (#6705) ... ## Description This pull request adds the profile feature in the Sway compiler. It communicates with an external `forc-perf` executable in order to signal the beginning and end of different compilation phases for profiling purposes. (re-opening of https://github.com/FuelLabs/sway/pull/6565) ## 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: Camden Smallwood <camden.smallwood@gmail.com> Co-authored-by: GeorgiosDelkos <georgios.delkos@ourovoros.io> Co-authored-by: IGI-111 <igi-111@protonmail.com>	2024-11-15 00:00:23 +00:00
Kaya Gökalp	ccd86925f9	chore: remove uwuify feature (#6698)	2024-11-06 05:46:40 -08:00
Kaya Gökalp	9c4a339dff	chore: remove unmaintained ansi_term in favor of ansiterm (#6696) ... ## Description related to #2601. Removes ansi_term dependency from sway crates. To remove the dependency completely from dep tree we need a release of sway repo to get a new version of forc_util and use it in forc_wallet as forc_wallet is depending on `forc-util v0.47.0` which uses `ansi_term`. Once that is done we can close #2601	2024-11-06 01:42:25 -08:00
IGI-111	d7dd104dac	Bump to v0.66.4 (#6688)	2024-11-03 17:12:45 +01:00
Vaivaswatha N	3ff63a59c1	EncodeBufferAppend: grow_if_needed should allocate sufficiently (#6686)	2024-11-02 11:47:58 +01:00
Vaivaswatha N	0555973393	Add configurables section offset in the preamble (#6522) ... The preamble now contains 8 bytes of offset to the configurables section. If there is no configurable const in the data-section, then the value of this integer will be equal to the size of the binary itself. This also means that we now sort the data-section to have all the non-configurables first, and then the configurables. The preamble final asm looks like this (the offset to configurables is 0'd out here in the example): ``` ;; ASM: Final program ;; Program kind: Script .program: move $$tmp $pc jmpf $zero i10 DATA_SECTION_OFFSET[0..32] DATA_SECTION_OFFSET[32..64] CONFIGURABLES_OFFSET[0..32] CONFIGURABLES_OFFSET[32..64] lw $$ds $$tmp i1 add $$ds $$ds $$tmp ``` The preamble bytecode looks like this: ``` 0x00000000 MOVE R60 $pc ;; [26, 240, 48, 0] 0x00000004 JMPF $zero 0xa ;; [116, 0, 0, 10] 0x00000008 ;; [0, 0, 0, 0, 0, 0, 2, 40] 0x00000010 ;; [0, 0, 0, 0, 0, 0, 0, 0] 0x00000030 LW R63 R60 0x1 ;; [93, 255, 192, 1] 0x00000034 ADD R63 R63 R60 ;; [16, 255, 255, 0] ... ``` --------- Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com> Co-authored-by: IGI-111 <igi-111@protonmail.com>	2024-10-29 20:16:33 +01:00
Kaya Gökalp	4efd248e36	chore: bump rust version to 1.82 (#6672) ... ## Description Bumps sway version used in CI to v1.82 --------- Co-authored-by: IGI-111 <igi-111@protonmail.com>	2024-10-28 15:41:25 +01:00
Daniel Frederico Lins Leite	ddb505d263	migrate encoding v1 to sway-features (#6586) ... ## Description This PR starts the implementation of https://github.com/FuelLabs/sway-rfcs/blob/master/rfcs/0013-changes-lifecycle.md. ## CLI flags Now, all `CLI`s, including our tests, support two new arguments ``` ... --experimental <EXPERIMENTAL> Comma separated list of all experimental features that will be enabled [possible values: new_encoding, storage_domains] --no-experimental <NO_EXPERIMENTAL> Comma separated list of all experimental features that will be disabled [possible values: new_encoding, storage_domains] ... ``` Experimental features can also be enabled inside `Forc.toml` for workspaces and individual projects. ``` experimental = { encoding-v1 = true } ``` And can be enabled using environment variables: ``` FORC_NO_EXPERIMENTAL=feature_a,feature_b FORC_EXPERIMENTAL=feature_c forc build ... ``` These configurations are applied in a very specific order to allow them to be overwritten. The order from the weakest to the strongest is: 1 - Workspace `TOML` 2 - Project `TOML` 3 - CLI 4 - Environment variables. The rationale is: 1 - We want an easy way to enable and/or disable a feature for the whole workspace; 2 - But we want to allow projects to overwrite these features, when needed. These two are the suggested approach to configure experimental features, but we also want to allow someone to easily turn on or off features to test something in particular. For that one can use the CLI flags; and in the specific case one does not have access to the CLI, for example, when one of the `SDK` is compiling the code, one can still completely overwrite the `TOML` files using environment variables. We are also applying the "no experimental" first. This is to allow the use case of exactly controlling which features will be enabled and disabled. In this case one can use the "meta-feature" `all` to disable everything and enable only the desired features. For example: ``` FORC_NO_EXPERIMENTAL=all FORC_EXPERIMENTAL=new_encoding your_command.... ``` ## Test for "-h" This PR also introduces snapshot tests for "-h" for all forc commands at https://github.com/FuelLabs/sway/pull/6586/files#diff-20a5e677d2ae9266a2247739b6a473d2ad0c627955187d668822e7d194f8e940 ## Multiple test.toml This PR also enables the use of multiple `test.toml`. Now each `test.toml` will be a different test, allowing the same code to be compiled and asserted differently. For example, `main_args_empty` has two files: the normal `test.toml` and a new `test.encoding_v1.toml`. One has `new_encoding` enabled and the other disabled. When a `test.toml` file has the `experimental` field, we do not use fields with `_new_encoding` suffix anymore, making these files simpler: test.toml: ```toml category = "run" # (1336, 1) script_data = "0000000000000538 0000000000000001" expected_result = { action = "return", value = 1337 } validate_abi = true experimental = { encoding_v1 = false } ``` test.encoding_v1.toml ``` script_data = "0000000000000538 0000000000000001" expected_result = { action = "return_data", value = "0000000000000539" } experimental = { new_encoding = true } ``` Test tomls with a suffix use `test.toml` as a base. So we do not need to repeat every field in them. Now when we run a test, we will see two tests instead of just one: ``` ... Testing should_pass/language/main_args/main_args_empty (test.encoding_v1.toml) ... ok Testing should_pass/language/main_args/main_args_empty (test.toml) ... ok ... ``` ## Conditional compilation It is also possible to use conditional compilation using these experimental features. Examples can be found inside `sway-lib-std`. ```sway #[cfg(experimental_new_encoding = true)] pub fn assert_eq<T>(v1: T, v2: T) { ... } ``` ## 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>	2024-10-28 11:34:03 +01:00
Alfie John	e1546f60ee	Version bump the remaining crate dependencies (#6579) ... ## Description As part of #6179, this PR updates the remaining quick-fix crates to their latest X.Y versions. Code fixes were needed to get compilation working and tests passing. Issue #6536 lists the crates that will need a bit more work to get working and passing. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] 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.	2024-09-23 08:44:31 +02:00
Alfie John	ab1e030f98	Move all crate dependencies to the workspace Cargo.toml (#6179) (#6563) ... ## Description For #6179, PR #6501 kept bumping into errors as it was doing too many things, so I've split that PR into multiple PRs. This is the first, and the only thing it does is move all of the various `Cargo.toml` dependencies into the single workspace `Cargo.toml`. Future PRs will: - Update dependency versions - Update code that breaks from the version bumps ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2024-09-21 09:48:34 +10:00
Joshua Batty	cba9a005ef	chore: bump to v0.63.6 (#6556) ... ## Description Bumps repo to v0.63.6 waiting on #6555	2024-09-18 12:45:46 -07:00
Sophie Dankel	7ab1565498	feat: Add --raw-logs option for forc-test (#6528) ... ## Description Closes https://github.com/FuelLabs/sway/issues/6015 - Adds the `--raw-logs` option - Removes the `decode` option as this is now the default for `--logs` - Shortens `--pretty-print` to `--pretty` ## Checklist - [x] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] 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.	2024-09-13 15:33:18 -07:00
Kaya Gökalp	31a1d6f983	chore: bump to v0.63.5 (#6508) ... ## Description Bumps repo to v0.63.5	2024-09-06 18:31:11 +00:00
IGI-111	2538442a67	Bump to v0.63.4 (#6503)	2024-09-05 20:30:44 +02:00
Joshua Batty	f55c81cce6	Bump to v0.63.3 (#6483)	2024-08-28 23:57:55 -07:00
IGI-111	a9e83955bc	Bump to v0.63.2 (#6476)	2024-08-28 23:06:10 +02:00