502 commits

Author	SHA1	Message	Date
xunilrj	5208360965	fix sroa for arrays	2025-08-01 16:38:04 -03: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
zees-dev	8b29cc39c5	feat: forc-mcp auth for mcp server hosting (#7300) ... ## Description This PR introduces api-key based auth (and management endpoints for an admin account) for the `forc-mcp` HTTP server. Functionality includes: - Admin-only API key management endpoints for creating, listing, viewing, and deleting API keys - Enhanced rate limiting with separate limits for public and authenticated requests - Flexible authentication modes supporting both public access and API-key-only operation The docs have been updated with details on how to add MCP server with auth for claude and cursor. Addresses https://github.com/FuelLabs/sway/issues/7301 <details> <summary>Admin Endpoints</summary> All admin endpoints require authentication with an admin API key via `X-API-Key` header: #### `POST` `/admin/api-keys` - Creates new user-level API keys - Returns the generated API key (shown only once for security) - Generated keys use secure SHA256 hashing with `mcp_` prefix #### `GET` `/admin/api-keys` - Lists all API keys with usage statistics - Optional include_admin=true query parameter to include admin keys - Shows real-time usage counters and rate limit status #### `GET` `/admin/api-keys/{key_id}` - Retrieves details for a specific API key - Returns `404` for admin keys to maintain security - Includes current usage statistics #### `DELETE` `/admin/api-keys/{key_id}` - Deletes specific API keys - Prevents deletion of admin keys (returns 403) - Returns `204` on successful deletion #### `POST` `/admin/import` - Bulk imports API keys with historical usage data - Supports merge mode (default) or replace mode with `clear_existing: true` - Useful for migration or backup restoration </details> ### Dual-Tier Rate Limiting System #### Public Requests (no API key): - Default: `10` requests/minute, `1,000` requests/day - Tracked by client IP address #### Authenticated Requests (with API key): - Default: `120` requests/minute, `10,000` requests/day - Admin keys have unlimited access - Tracked per API key with usage persistence #### Intelligent Counter Reset Logic - Per-minute counters reset after `60` seconds - Daily counters reset at midnight (UTC date change) ### Authentication Modes - Mixed Mode (Default) - Allows both public and authenticated access - Public requests get lower rate limits - API key holders get higher rate limits - API Keys Only Mode - Set `api_keys_only: true` in configuration - Rejects all requests without valid API key - Suitable for production deployments requiring authentication ### Testing - Unit tests for authentication middleware - Integration tests for admin endpoints - Rate limiting validation tests - API key lifecycle tests (create, use, delete) - Security tests (unauthorized access, role escalation) - Persistence tests (file storage, restart recovery) ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: z <zees-dev@users.noreply.github.com> Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2025-07-31 18:13:37 +12:00
Mike Christopher	688242c07f	feat: check file descriptor limits before running forc node (#7302) ... ## Description Adds a check to try and set the `NOFILE` limit on Unix-based systems. This is important for RocksDB, since we generally exceed the default maximum number of allowed file descriptors allowed by the OS. The idea is to attempt to raise that limit to a reasonable number, and throw an error if we are unable to (likely due to user permission issues). ## Checklist - [ ] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers.	2025-07-31 11:31:43 +10:00
Joshua Batty	c7ff31207a	Add parallel processing to forc-doc using rayon to improve performance (#7296) ... ## Description Key changes: - Parallelize document rendering and link generation - Add type aliases for complex nested types (`DocLinkMap`, `ModuleMap`, `RenderResult`) - Remove unnecessary wrapper functions and clones The parallel processing maintains insertion order through sequential merging, ensuring identical documentation output. Not sure why the codspeed report isn't showing this below but when I run `cargo bench` locally i'm seeing these results. | Metric | Before | After | Improvement | |--------|--------|-------|-------------| | build_std_lib_docs | 70.069 ms | 43.227 ms | **43.2% faster** | ## Checklist - [ ] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-07-30 14:21:46 +04:00
zees-dev	4c9c4c29bf	feat: forc mcp server - with forc-call tool integration (#7284) ... ## Description Introducing Forc-MCP module (CLI). The MCP server can be run in 3 modes: - `stdio` - `sse`: long-running server - using http server-side-events - `http`: long-running server - using http streams ### Forc-call integration The first tool to be integrated is `forc-call` - which exposes the following tool calls: - `list_contract_functions` - `transfer_assets` - `get_execution_trace` - `call_contract` And the following resources: - `MCP Type Encoding Reference` - `MCP Tool Usage Examples` - `Contract Examples with MCP Tools` ### Screenshots from `@modelcontextprotocol/inspector` <img width="2543" height="549" alt="Screenshot 2025-07-15 at 5 09 16 PM" src="https://github.com/user-attachments/assets/aaab5174-d5e6-4685-be71-fd17cd4f5d0f" /> <img width="2540" height="531" alt="Screenshot 2025-07-15 at 5 09 30 PM" src="https://github.com/user-attachments/assets/9ab39d5a-950c-4404-a3a3-6e34b89f58e7" /> ### Example usage (claude code) Pre-requisites: - Run local fuel-core node ``` fuel-core run --ip 127.0.0.1 --port 4000 --db-type rocks-db --debug --historical-execution ``` - Deploy a contract to local node: `forc deploy --default-signer` 1. Run the MCP server (using http-steam in this example): ``` cargo run -p forc-mcp -- http ``` 2. Add mcp server to claude ``` claude mcp add --transport http forc-mcp-http http://localhost:3001/mcp ``` 3. Use claude/LLM to interact with MCP server <details> <summary>Claude output</summary> ``` ╭───────────────────────────────────────────────────╮ │ ✻ Welcome to Claude Code! │ │ │ │ /help for help, /status for your current setup │ │ │ │ cwd: /Users/z/Desktop/fuellabs/sway │ ╰───────────────────────────────────────────────────╯ > Use the forc-mcp-http. Given the following sway contract: demo/demo/src/main.sw deployed at the following address: ae40e8dbe366c5ac61fe558e4e9139300534cd5d9463522621a903464c441eb2 Using the forc-mcp-http: > list all its callable functions. > can you get the current count? > tell me how much gas it would cost to increment the count. > show me the execution trace for incrementing the count. ⎿ ⧉ Selected 14 lines from scratch/ai/templates.md in Cursor ⏺ I'll help you interact with the deployed Sway contract using forc-mcp-http. Let me start by reading the contract to understand its structure, then perform the requested operations. ⏺ Read(demo/demo/src/main.sw) ⎿ Read 34 lines (ctrl+r to expand) ⏺ Now I need to find the ABI file for this contract to use with the forc-mcp-http tools: ⏺ Search(pattern: "demo/demo/out/**/*.json") ⎿ Found 7 files (ctrl+r to expand) ⏺ Perfect! I found the ABI file and a deployment file that matches the contract address. Let me read the ABI: ⏺ Read(demo/demo/out/release/demo-abi.json) ⎿ Read 89 lines (ctrl+r to expand) ⏺ Now let me use the forc-mcp-http tools to interact with the contract. First, I'll list all callable functions: ⏺ forc-mcp-http:list_contract_functions (MCP)(abi: "/demo/demo/out/rele ase/demo-abi.json", contract_id: "ae40e8dbe366c5ac61fe55 8e4e9139300534cd5d9463522621a903464c441eb2") ⎿ Callable functions for contract: ae40e8dbe366c5ac61fe558e4e9139300534cd5d9463522621a903464c441eb2 get_count() -> u64 … +186 lines (ctrl+r to expand) ⏺ Now let me get the current count: ⏺ forc-mcp-http:call_contract (MCP)(abi: "/demo/demo/out/release/demo-a bi.json", contract_id: "ae40e8dbe366c5ac61fe558e4e9139300534cd5d94 63522621a903464c441eb2", function: "get_count") ⎿ { "tx_hash": "0f1e868e75530f33d37748cac9ae25c33bf166c9e02d28e36f3ffdd67ecf3584", "total_gas": 65007, … +354 lines (ctrl+r to expand) ⏺ Now let me check the gas cost for incrementing the count using dry-run mode: ⏺ forc-mcp-http:call_contract (MCP)(abi: "/demo/demo/out/release/demo-a bi.json", contract_id: "ae40e8dbe366c5ac61fe558e4e9139300534cd5d94 63522621a903464c441eb2", function: "increment_count", function_args: ["(1, 2)"], mode: "dry-run") ⎿ Error: Contract call failed: input must start with '{' and end with '}': (1, 2) ⏺ Let me fix the format for the struct argument: ⏺ forc-mcp-http:call_contract (MCP)(abi: "/demo/demo/out/release/demo-a bi.json", contract_id: "ae40e8dbe366c5ac61fe558e4e9139300534cd5d94 63522621a903464c441eb2", function: "increment_count", function_args: ["{\"vals\": [1, 2]}"], mode: "dry-run") ⎿ Error: Contract call failed: input must start with '(' and end with ')': "vals": [1, 2] ⏺ Let me try the tuple format as shown in the example: ⏺ forc-mcp-http:call_contract (MCP)(abi: "/demo/demo/out/release/demo-a bi.json", contract_id: "ae40e8dbe366c5ac61fe558e4e9139300534cd5d94 63522621a903464c441eb2", function: "increment_count", function_args: ["((1, 2))"], mode: "dry-run") ⎿ Error: Contract call failed: input must start with '{' and end with '}': ((1, 2)) ⏺ Let me try with the correct struct format: ⏺ forc-mcp-http:call_contract (MCP)(abi: "/demo/demo/out/release/demo-a bi.json", contract_id: "ae40e8dbe366c5ac61fe558e4e9139300534cd5d94 63522621a903464c441eb2", function: "increment_count", function_args: ["{(1, 2)}"], mode: "dry-run") ⎿ { "tx_hash": "f694c73230e893b00968d8106f5bafbcd585c2cf0f4aea1c6a562ce7e1868690", "total_gas": 78940, … +399 lines (ctrl+r to expand) ⏺ Perfect! Now let me get the execution trace for that increment operation: ⏺ forc-mcp-http:get_execution_trace (MCP)(total_gas: 78940, trace_events: [{"Call":{"index":0,"method ":"increment_count","arguments":["Adder { vals: (1, 2) }"],"to":"ae40e8dbe366c5ac61fe558e4e9139300534cd5d9463522621 a903464c441eb2","amount":0,"gas":26222}},{"LogData":{"index" :2,"id":"ae40e8dbe366c5ac61fe558e4e9139300534cd5d9463522621a 903464c441eb2","value":"3","len":8}},{"ReturnData":{"index": 4,"id":"ae40e8dbe366c5ac61fe558e4e9139300534cd5d9463522621a9 03464c441eb2","data":"()"}},{"Return":{"index":6,"id":"00000 00000000000000000000000000000000000000000000000000000000000" ,"val":1}},{"ScriptResult":{"index":7,"result":"Success","ga s_used":22210}}]) ⎿ Traces: [Script] ├─ [26222] 0xae40e8dbe366c5ac61fe558e4e9139300534cd5d9463522621a903464c441eb2:: … +8 lines (ctrl+r to expand) ⏺ Summary Here are the results for the deployed Sway contract at ae40e8dbe366c5ac61fe558e4e9139300534cd5d9463522621a903464c441eb2: Callable Functions: 1. get_count() → returns u64 (read-only) 3. increment_count(adder: Adder) → returns () (read/write storage) Current Count: The current count is 1 Gas Cost for Increment: Incrementing the count with Adder { vals: (1, 2) } costs 78,940 gas total (22,210 gas used by script) Execution Trace: The increment operation: - Calls increment_count with Adder { vals: (1, 2) } - Uses 26,222 gas for the contract call - Emits a log with value 3 (0 + 1 + 2 = 3, the new count) - Returns () (unit/void) - Total script gas used: 22,210 - Result: Success The contract adds the two values from the Adder struct (1 + 2 = 3) to the current storage count (0) and logs the result. ``` </details> ## Checklist - [ ] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: z <zees-dev@users.noreply.github.com>	2025-07-24 08:18:31 -07:00
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
kaya	8963312ba8	feat: add preliminary local checks for forc-publish (#7253) ... ## Description closes #7252. This pull request introduces enhancements to the `forc-publish` plugin, focusing on validating project configurations and improving error handling. Key changes include the addition of a `validate` module for preemptive checks, updates to error definitions, and modifications to the tarball creation logic to incorporate validation. New test cases and sample data directories have also been added to ensure robust validation functionality. ### Validation Enhancements: * Added a new `validate` module in `forc-publish/src/validate.rs` to check for missing `Forc.toml`, missing version fields, and unsupported dependency types. * Updated the `Error` enum in `forc-publish/src/error.rs` to include new error variants for validation failures like `InvalidForcToml`, `MissingVersionField`, and `DependencyMissingVersion`. ### Tarball Creation Updates: * Refactored `create_tarball_from_current_dir` in `forc-publish/src/tarball.rs` to use the new `validate_dir` function for preemptive validation. Removed redundant checks for `Forc.toml` existence. * Adjusted test cases in `forc-publish/src/tarball.rs` to use sample directories with predefined configurations for validation testing. [[1]](diffhunk://#diff-e3f20cadab3a1cf99fc967e0adc12e908f435a185e1529df9b152388927adf45L79-R85) [[2]](diffhunk://#diff-e3f20cadab3a1cf99fc967e0adc12e908f435a185e1529df9b152388927adf45L140-R135) ### Test Data Additions: * Added sample directories under `tests/data` for various validation scenarios, including projects with missing versions, dependencies without versions, and valid configurations. [[1]](diffhunk://#diff-b171d6da23a1fe36735cd962cfcf506831115c3714654236b31dd999c2853823R1-R11) [[2]](diffhunk://#diff-016348eaea4a95d041537b29d370619ab0d5ca99cc84f9b30d8ad561aa757a1eR1-R9) [[3]](diffhunk://#diff-0495f782769450a8c200fdcc1f29805f4811a26f4849720fa34d5b37ba45e471R1-R8) * Included `.gitignore` files in test data directories to exclude `out` and `target` folders.	2025-07-22 02:03:58 +00:00
Daniel Frederico Lins Leite	0339852289	Better observability for the compiler (#7250) ... ## Description Whilst finishing "const generics" I spent a LOT of time trying to find why some cases where not working. Until I found the issue on a "indirect input" for the method `type_check_method_application`. The issue is that some other method was returning a wrong value, and although the solution is not hard, there is no way to fix just this problem, and there is no way to assert this returned value to guarantee that the problem will not return. To start to improve these kind of tests, and help debug problems, this PR start to create a "callback" mechanism that allows anyone using the compiler as a library, this will not be available at the CLI, to inspect and control logging. The integration in out e2e test harness is done by the `test.toml`. ``` category = "run" expected_result = { action = "return", value = 1 } expected_result_new_encoding = { action = "return_data", value = "0000000000000001" } validate_abi = true logs = """ if pkg != "std" && event == "on_before_method_resolution" && method == "len_xxx" { print_args(); trace(true); } if pkg != "std" && event == "on_after_method_resolution" && method == "len_xxx" { print_args(); trace(false); } """ ``` The `harness` framework will not call "logs" for every callback that happens outside of the "std" library. To allow interaction with the harness itself, some commands are available: - `print_args` print all the available arguments for that event on the "snapshot"; - `trace` enables/disables trace level logging, that also end up in the "snapshot". In the example above, we will generate the following snapshot: ``` --- source: test/src/e2e_vm_tests/harness_callback_handler.rs assertion_line: 14 --- on_before_method_resolution: FromModule { method_name: len_xxx }; Regular([]); S<unresolved T -> u64, N -> 3> before get_method_safe_to_unify: S<unresolved T -> u64, N -> 3> len_xxx<N -> None>(self: unresolved Self -> S<unresolved T -> T, N -> None>): u64 -> u64 after get_method_safe_to_unify: S<unresolved T -> u64, N -> 3>; len_xxx<N -> 3>(self: unresolved Self -> S<unresolved T -> u64, N -> None>): u64 -> u64 on_after_method_resolution: FromModule { method_name: len_xxx }; Regular([]); S<unresolved T -> u64, N -> 3>; len_xxx<N -> 3>(self: unresolved Self -> S<unresolved T -> u64, N -> None>): u64 -> u64; S<unresolved T -> u64, N -> 3> on_before_method_resolution: FromModule { method_name: len_xxx }; Regular([]); S<unresolved T -> u64, N -> 3> before get_method_safe_to_unify: S<unresolved T -> u64, N -> 3> len_xxx<N -> None>(self: unresolved Self -> S<unresolved T -> T, N -> None>): u64 -> u64 after get_method_safe_to_unify: S<unresolved T -> u64, N -> 3>; len_xxx<N -> 3>(self: unresolved Self -> S<unresolved T -> u64, N -> None>): u64 -> u64 ``` The important part is that the problem I want to fix it's there. On the line of "get_method_safe_to_unify", the "self" parameter const generic argument "N" is not being materialized, although the method resolution pass started with a fully materialized type. With this callback machinery it becomes easier to debug the problems, and possible to generate asserts to internal methods. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers.	2025-07-18 07:24:32 +00:00
Igor Rončević	e303b0f1ab	Add migration for new_hashing (#7287) ... ## Description This PR: - implements "Review existing usages of `StorageMap`, `sha256`, and `keccak256`" migration step for `new_hashing` experimental feature, as described in the Breaking Changes chapter of the tracking issue #7256. - extends the migration infrastructure by providing an optional help message related to an occurrance in code. Instead of returning only `Span`, migration steps now return an `Occurrance` that combine the `Span` with an optional help message. - extends the migration infrastructure to visit all the `TyExpressionVariant`s. For some of the expressions, the typed elements are still not provided. In such cases the migration step for `new_hashing` still detects an occurrence, but the help message lacks the detailed type information. - extends the migration infrastructure to visit all the declarations relevant for the `new_hashing` migration step. E.g.; `trait`, `abi`, and `storage` decls. Additionally, the PR implements `AsRawSlice` for `str`. Here is an excerpt of an output of the migration step run on a test project: ```console info: [new_hashing] Review existing usages of `StorageMap`, `sha256`, and `keccak256` --> /src/test.sw:62:39 | ... 12 | let _ = sha256("affected"); | ---------- info: This has type "str". ... 24 | let user_metadata_key_id = sha256((user_id, key)); | -------------- info: This has type "(b256, String)", that recursively contains "Bytes". | 71 | let _ = sha256_alias(StructCRec::new()); | ----------------- info: This has type "StructCRec", that recursively contains "Vec<u8>". | ::: /src/main.sw:52:5 | ... 13 | let _ = sha256(x); | - info: This has generic type "T". Review all the concrete types used with it. | 39 | directly_affected_str_array: StorageMap<str[3], u64> = StorageMap {}, | --------------------------- info: Review this storage field, because of "str[3]" in "StorageMap" key. | 43 | nested_affected_storage_maps: StorageMap<StructA, StorageMap<raw_slice, StorageMap<EnumARec, StorageVec<StorageMap<str[3], u64>>>>> = StorageMap {}, | ---------------------------- info: Review this storage field, because of "[u8; 0]", "slice", "[u8; 0]", and "str[3]" in "StorageMap" keys. | 52 | metadata: StorageMetadata = StorageMetadata {}, | -------- info: Review this storage field, because of potential custom storage type "StorageMetadata". 56 | 72 | storage.metadata.insert(sha256(handle_name), key, value); | ----------- info: This has type "String", that contains "Bytes". | | = help: New hashing changes the hashes of instances of the following types: = help: - string slices (`str`) = help: - string arrays (`str[N]`) = help: - arrays (`[T; N]`) = help: - raw slices (`raw_slice`) = help: - vectors (`std::vec::Vec<T>`) = help: - bytes (`std::bytes::Bytes`) = help: = help: To decide if opting-in to new hashing is backward-compatible and safe or not, = help: review if those types are directly used, or are contained in types: = help: - used as keys in `StorageMap`s, = help: - used in custom storage types, = help: - hashed using `sha256` or `keccak256` functions. = help: = help: ╔═════════════════════════════════════════════════════════════════════════════════════╗ = help: ║ The above occurrences must not be seen as comprehensive, but rather as a guideline. ║ = help: ║ Carefully review all the storage access and hashing patterns in your code. ║ = help: ║ E.g., using precomputed hashes, having custom `Hash` implementations, and similar. ║ = help: ╚═════════════════════════════════════════════════════════════════════════════════════╝ = help: = help: For a detailed migration guide see: https://github.com/FuelLabs/sway/issues/7256 ``` ## 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-07-18 04:40:36 +00:00
IGI-111	b68a3861db	Bump to v0.69.1 (#7289)	2025-07-17 11:48:56 -07: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
kaya	403a7e5780	feat: add mdbook preprocessing for forc-publish to flatten include directives (#7264) ... ## Description closes #7263 This pull request introduces functionality to preprocess Markdown files by handling `{{#include}}` directives, enabling the inclusion of content from other files. It also integrates this functionality into the `forc-publish` plugin to process `README.md` files during tarball creation. The most important changes include the addition of the Markdown preprocessing module, updates to error handling, and modifications to the tarball creation process. ### Markdown Preprocessing Functionality: * [`forc-plugins/forc-publish/src/md_pre_process/mod.rs`](diffhunk://#diff-1d065227f3eea45f66a3189882f220de977df2e1b7d1fb2de36d2b9baeb39a7aR1-R293): Added a new module to preprocess Markdown files, including features like dependency graph construction, topological sorting, and content flattening for `{{#include}}` directives. Includes comprehensive tests for edge cases like cycles and missing includes. * [`forc-plugins/forc-publish/src/md_pre_process/error.rs`](diffhunk://#diff-2cb6edf1287489eb7edd794db5e8b727907a28755871f656cfce877aadd886c2R1-R25): Introduced a dedicated error type `MDPreProcessError` to handle issues like I/O errors, missing include files, and cycles in Markdown dependencies. ### Integration with `forc-publish` Plugin: * [`forc-plugins/forc-publish/src/lib.rs`](diffhunk://#diff-8b5115a5299062687979272a86a86b573a688194c06c044174da61798ef41574R4): Registered the new `md_pre_process` module in the plugin library. * [`forc-plugins/forc-publish/src/tarball.rs`](diffhunk://#diff-e3f20cadab3a1cf99fc967e0adc12e908f435a185e1529df9b152388927adf45R29-R31): Updated the tarball creation process to preprocess `README.md` files using the `flatten_markdown` function. Added a warning mechanism to log errors without failing the publish process. [[1]](diffhunk://#diff-e3f20cadab3a1cf99fc967e0adc12e908f435a185e1529df9b152388927adf45R29-R31) [[2]](diffhunk://#diff-e3f20cadab3a1cf99fc967e0adc12e908f435a185e1529df9b152388927adf45R44-R60) ### Error Handling Enhancements: * [`forc-plugins/forc-publish/src/error.rs`](diffhunk://#diff-d09f44c4690282b827488db75a21e561e1e6fa72d549904db3f5fc4313f4819cR34-R36): Extended the `Error` enum to include `MDPreProcessError` for better error propagation during Markdown preprocessing. ### Dependency Updates: * [`forc-plugins/forc-publish/Cargo.toml`](diffhunk://#diff-2bd34a7b1fa0f1850ad25c6e080d410b2df98c16b6cd75445a138d04e617311aR29): Added `regex` as a workspace dependency to support Markdown parsing.	2025-07-09 10:18:31 +04:00
zees-dev	b54fce7727	feat: forc-call inline abi support (#7270) ... ## Description This pull request introduces a enhancement to the ABI handling in the `forc-client` plugin by replacing the `Either<PathBuf, Url>` type with a new `AbiSource` enum. This improves flexibility and usability by supporting ABI sources as file paths, URLs, or raw JSON strings. Additionally, it simplifies related code and updates documentation and tests accordingly. This represents an additional optional for callers to use forc-call with an ABI available at-hand without needing to write to a file first. ## 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-04 08:01:13 +00:00
Joshua Batty	de2a5ac0f0	Add workspace support to forc-doc (#7268) ... ## Description Adds workspace-level documentation support to `forc doc`. When invoked from the root of a workspace, it now generates a landing page that lists all member libraries along with their descriptions extracted directly from each `Forc.toml`. Below is an example of the landing page generated when running `forc doc` at the root of the `sway-libs` workspace.  Closes https://github.com/FuelLabs/sway/issues/4103 ## 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.	2025-07-04 00:40:11 -07:00
GarmashAlex	73fb34320e	Fix broken link to test data directory in README (#7266) ... ## Description Update all references in the README from the outdated src/tests/data path to the current tests/fixtures directory. This ensures that documentation and example commands accurately reflect the present project structure, preventing confusion and errors for users and contributors. ## Checklist - [ ] 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). - [ ] 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: kaya <20915464+kayagokalp@users.noreply.github.com>	2025-07-01 14:47:55 +00:00
kaya	5265dd7405	fix: typo in comment for forc-migrate (#7269) ... ## Description Unblocks the sway CI by fixing a typo in forc-migrate	2025-07-01 18:23:28 +12: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
Joshua Batty	ceedc94283	Add criterion benchmark to forc-doc + initial code quality pass (#7242) ... ## Description Doing some general code quality changes at the same time. ## Checklist - [ ] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers.	2025-06-30 08:34:43 +00:00
zees-dev	0ac606c132	forc-call detailed vm-interpreter call traces (#7251) ... ## Description This PR updates the `forc call` functionality to provide detailed call traces. This is achieved via retrieving `Vec<StorageReadReplayEvent>` from transactions (dry-run and/or live mode) and executing these in a vm-interpreter. - The approach is inspired by code snippets from this repo: https://github.com/FuelLabs/execution-trace ### Additional `forc-call` updates: - introduction of contract address labelling via `--label <contract-addr>:<name>` - introduction of providing additional contract abis via `--contract-abi <contract-addr>:<abi-file-or-url>` #### Example Assume the following 2 contracts - where `demo-caller` calls `demo` contract: - `demo`: `0xe84e278cb083a5b3ff871f1d3de26fdd13ae044070e1bbda18b60a13f98bb295` - `demo-caller`: `0xed4437b191cc78a02df048f21a73df37f1627efdde7d7e4232468b9de9d83485` <details> <summary>demo contract source</summary> ```sway contract; use std::{logging::log}; struct Adder { vals: (u64, u64), } abi Demo { #[storage(read)] fn get_count() -> u64; #[storage(read, write)] fn increment_count(adder: Adder); } storage { count: u64 = 0, } impl Demo for Contract { #[storage(read)] fn get_count() -> u64 { storage.count.read() + 1 } #[storage(read, write)] fn increment_count(adder: Adder) { let new_count = storage.count.read() + adder.vals.0 + adder.vals.1; storage.count.write(new_count); log(new_count); } } ``` </details> <details> <summary>demo-caller contract source</summary> ```sway contract; use std::contract_id::ContractId; struct Adder { vals: (u64, u64), } abi Demo { #[storage(read)] fn get_count() -> u64; #[storage(read, write)] fn increment_count(adder: Adder); } abi DemoCaller { #[storage(read, write)] fn call_increment_count(adder: Adder) -> u64; #[storage(read)] fn check_current_count() -> u64; } const CONTRACT_ID = 0xe84e278cb083a5b3ff871f1d3de26fdd13ae044070e1bbda18b60a13f98bb295; impl DemoCaller for Contract { #[storage(read, write)] fn call_increment_count(adder: Adder) -> u64 { let demo = abi(Demo, CONTRACT_ID); demo.increment_count(adder); log("incremented count"); log(demo.get_count()); log("done"); demo.increment_count(Adder { vals: (5, 2) }); demo.get_count() } #[storage(read)] fn check_current_count() -> u64 { let demo = abi(Demo, CONTRACT_ID); demo.get_count() } } ``` </details> **Previous functionality**: ```sh cargo run -p forc-client --bin forc-call -- \ --abi ./demo/demo-caller/out/release/demo-caller-abi.json \ ed4437b191cc78a02df048f21a73df37f1627efdde7d7e4232468b9de9d83485 \ call_increment_count "{(1,1)}" -vvv ``` **Output**: <img width="721" alt="Screenshot 2025-06-24 at 12 14 53 PM" src="https://github.com/user-attachments/assets/2ef77293-54eb-46c3-989a-b7f8cf9d236c" /> **Updated functionality**: ```sh cargo run -p forc-client --bin forc-call -- \ --abi ./demo/demo-caller/out/release/demo-caller-abi.json \ ed4437b191cc78a02df048f21a73df37f1627efdde7d7e4232468b9de9d83485 \ --contract-abi e84e278cb083a5b3ff871f1d3de26fdd13ae044070e1bbda18b60a13f98bb295:./demo/demo/out/release/demo-abi.json \ --label ed4437b191cc78a02df048f21a73df37f1627efdde7d7e4232468b9de9d83485:demo-caller \ --label e84e278cb083a5b3ff871f1d3de26fdd13ae044070e1bbda18b60a13f98bb295:demo \ call_increment_count "{(1,1)}" -vv ``` **Output**: <img width="760" alt="Screenshot 2025-06-24 at 12 15 25 PM" src="https://github.com/user-attachments/assets/442c0a97-80f8-46b6-bdf9-d67952c28b58" /> ### Other misc. improvements to `forc-call` - refactor of the forc-call verbosity levels and functions (arguably cleaner code) - re-write of the tracing to simply process receipts and indent via stack - instead of recursively constructing node-call tree - closes https://github.com/FuelLabs/sway/issues/7197 ## AI description This pull request introduces significant enhancements to the `forc call` functionality, improving usability, debugging, and trace readability for multi-contract interactions. The changes include support for labeled contract addresses, additional ABI files for better decoding, and updates to verbosity levels. Additionally, dependencies and internal parsing logic have been updated to support these features. ### Enhancements to `forc call` functionality: * **Support for labeled contract addresses:** - Added the `--label` flag to allow users to assign human-readable labels to contract addresses in transaction traces, improving readability. [[1]](diffhunk://#diff-466e2f9659cab303594eb73a846768ecdbc1a13030e5869cdac51ddde87dd313R289-R302) [[2]](diffhunk://#diff-4ee92d729fce66f7e7aed1fc29b41834951eb63198e0da747b9b9e45d13f717bR248-R320) - Updated documentation to include examples of using labels in traces. [[1]](diffhunk://#diff-4ee92d729fce66f7e7aed1fc29b41834951eb63198e0da747b9b9e45d13f717bR63-R73) [[2]](diffhunk://#diff-466e2f9659cab303594eb73a846768ecdbc1a13030e5869cdac51ddde87dd313R184-R193) * **Support for additional ABIs:** - Introduced the `--contract-abi` flag to specify additional contract ABIs for decoding function signatures, parameters, and return values in multi-contract interactions. [[1]](diffhunk://#diff-466e2f9659cab303594eb73a846768ecdbc1a13030e5869cdac51ddde87dd313R289-R302) [[2]](diffhunk://#diff-466e2f9659cab303594eb73a846768ecdbc1a13030e5869cdac51ddde87dd313R209-R217) - Updated the parsing logic to handle additional ABIs and labels. - Documentation now includes examples and explanations for using additional ABIs. [[1]](diffhunk://#diff-4ee92d729fce66f7e7aed1fc29b41834951eb63198e0da747b9b9e45d13f717bR102-R115) [[2]](diffhunk://#diff-4ee92d729fce66f7e7aed1fc29b41834951eb63198e0da747b9b9e45d13f717bR248-R320) * **Improved verbosity and tracing:** - Adjusted verbosity levels to make transaction traces available at `-vv` instead of `-vvv`. - Enhanced trace output to include labeled contract addresses and decoded function information. [[1]](diffhunk://#diff-4ee92d729fce66f7e7aed1fc29b41834951eb63198e0da747b9b9e45d13f717bL253-R333) [[2]](diffhunk://#diff-4ee92d729fce66f7e7aed1fc29b41834951eb63198e0da747b9b9e45d13f717bR357-R413) ### Dependency and internal updates: * **Dependency additions:** - Added `fuel-core-storage` as a dependency in `Cargo.toml` to support new features. [[1]](diffhunk://#diff-2e9d962a08321605940b5a657135052fbcef87b5e360662bb527c96d9a615542R93) [[2]](diffhunk://#diff-f0f5128eecb15714bd0a80d1f03d87a84f375d0598471bb27e3bb388c188550cR49) * **Parsing and execution logic:** - Refactored `forc-client` to include reusable functions for parsing ABIs and labels. - Updated the `call_function` logic to handle additional ABIs and integrate with the new dry-run execution method. [[1]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeR54-R64) [[2]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeL137-R172) ## Checklist - [ ] I have linked to any relevant issues. - [ x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: z <zees-dev@users.noreply.github.com> Co-authored-by: kaya <20915464+kayagokalp@users.noreply.github.com>	2025-06-30 19:14:25 +12:00
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
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
Igor Rončević	f12c789b57	Optimize existing and add missing Hash implementations (#7238) ... ## Description This PR: - optimizes the existing `std:#️⃣:Hash` implementations in the `std`, for bytecode size and gas usage. The optimizations are based on eliminations of intensive memory allocations and memory copying. On a sample application, the **bytcode size reduction was ~10%**, and the **gas usage reduction >50%**. The detailed results are presented below. - fixes #7234 - adds `Hash` implementations for: - unit type `()`, - tuples of a single element `(T, )`, - empty arrays `[T; 0]`, - other `std` types that were missing `Hash` implementations, like, e.g.: `Duration`, `Time`, `U128`, `B512`, etc. Note that `Hash` implementations were not provided for various Error enums. ## Performance Optimizations To measure performance gains, a sample application was used, that: - hashed all built-in types individually, as well as tuples and array of those, and `Bytes` and `Vec`. - hashed all the above types within a same `Hasher`, simulating hashing of complex types like, e.g., structs. The bytcode size of the sample application got **reduced from 9560 to 8584 bytes (10.21% reduction)**. The overall gas usage for hashing types individually **got reduced from 35826 to 15562 (56.56% reduction)**. The overall gas usage for hashing types within a same `Hasher` **got reduced from 34951 to 14443 (58.67% reduction)**. The `in_language` tests for hashing, `hash_inline_tests`, also demonstrated a **significant reduction in gas usage, up to 57.82%**. A small regression is noticable when hashing empty types, e.g., unit. We expect that regression also to disappear once `const fn` is implemented, and local constants could be evaluated from generic functions. <details> <summary>Expand to see the detailed gas cost comparison for all `hash_inline_tests`</summary> | Test | Before | After | Percentage | |------|--------|-------|------------| | hash_address | 10070 | 6366 | 36.78% | | hash_array_10 | 33691 | 15867 | 52.90% | | hash_array_1 | 4870 | 3102 | 36.30% | | hash_array_2 | 8069 | 4517 | 44.02% | | hash_array_3 | 11219 | 5883 | 47.56% | | hash_array_4 | 14369 | 7249 | 49.55% | | hash_array_5 | 17519 | 8615 | 50.82% | | hash_array_6 | 20917 | 10229 | 51.10% | | hash_array_7 | 24109 | 11637 | 51.73% | | hash_array_8 | 27302 | 13046 | 52.22% | | hash_array_9 | 30494 | 14454 | 52.60% | | hash_array_empty | 773 | 777 | -0.52% | | hash_asset_id | 10070 | 6366 | 36.78% | | hash_b256 | 9604 | 5900 | 38.57% | | hash_b512 | 6028 | 4476 | 25.75% | | hash_bool | 3885 | 1993 | 48.70% | | hash_bytes | 8200 | 7112 | 13.27% | | hash_call_params | 11439 | 6019 | 47.38% | | hash_contract_id | 10070 | 6366 | 36.78% | | hash_duration | 4753 | 2985 | 37.20% | | hash_ed25519 | 18268 | 14780 | 19.09% | | hash_evm_address | 10098 | 6394 | 36.68% | | hash_fn_sha256_str_array | 1953 | 1167 | 40.25% | | hash_hasher_write_str | 2512 | 2013 | 19.86% | | hash_hasher_write_str_array | 2306 | 1807 | 21.64% | | hash_identity | 30526 | 14998 | 50.87% | | hash_input | 11766 | 5718 | 51.40% | | hash_message | 3003 | 3099 | -3.20% | | hash_option | 21373 | 9511 | 55.50% | | hash_output | 19649 | 9569 | 51.30% | | hash_point2d | 6861 | 4801 | 30.02% | | hash_public_key | 7372 | 7692 | -4.34% | | hash_result | 27083 | 11423 | 57.82% | | hash_scalar | 4159 | 3313 | 20.34% | | hash_secp256k1 | 18268 | 14780 | 19.09% | | hash_secp256r1 | 18268 | 14780 | 19.09% | | hash_signature | 31213 | 16936 | 45.74% | | hash_str | 6902 | 5417 | 21.52% | | hash_string | 5453 | 5252 | 3.69% | | hash_time | 4753 | 2985 | 37.20% | | hash_transaction | 23604 | 11508 | 51.25% | | hash_tuple_1 | 4834 | 3066 | 36.57% | | hash_tuple_2 | 7997 | 4445 | 44.42% | | hash_tuple_3 | 11147 | 5811 | 47.87% | | hash_tuple_4 | 14297 | 7177 | 49.80% | | hash_tuple_5 | 17447 | 8543 | 51.03% | | hash_u128 | 7943 | 4391 | 44.72% | | hash_u16 | 9384 | 5860 | 37.55% | | hash_u256 | 9600 | 5896 | 38.58% | | hash_u32 | 9384 | 5860 | 37.55% | | hash_u64 | 9372 | 5836 | 37.73% | | hash_u8 | 7740 | 3704 | 52.14% | | hash_unit | 771 | 775 | -0.52% | | hash_vec | 53077 | 33733 | 36.45% | </details> ## Breaking Changes Strictly seen, adding `Hash` implementations for `std` types like `Option<T>` represents a breaking change for those who eventually had their own implementations. However, if such implementations existed, after introducing strict trait coherence checks, they already became invalid, because neither the `Hash` trait nor the types `Hash` is implemented for are part of third party packages, but contained within the `std`. Thus, we can have a breaking change only if someone migrates from an older version that does not have trait coherence in place. But in that case, the trait coherence itself will already report breaking change errors. Because `Hash` implementations for `std` types must and should have already been provided within the `std`, we can treat adding those implementations as a bug fix. ## 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-06-18 10:47:50 -07:00
Igor Rončević	cd89f62ece	Add migration for renaming existing panic identifiers to r#panic (#7231) ... ## Description This PR: - implements the [Rename existing "panic" identifiers](https://github.com/FuelLabs/sway/issues/6765) migration step. - further extends the migration infrastructure by covering visiting additional expressions and declarations. As with all previous migrations, a pragmatic approach is taken between the invested effort and the gained coverage. The goal is to support migrating the use cases most probable in real-life code. Non-supported cases are documented in code comments. The PR is the last step in fully implementing #6765. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] 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-17 22:13:24 +10:00
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
kaya	6c30edbbe3	feat: implicitly depend on std from registry, not via git (#7204) ... ## Description closes #7040. With this PR we are marking the registry support *completed* we now have std deployed to forc.pub and forc using that std implicitly if no tag, branch, or specific git tag is supplied in env variables (this is needed by downstream, such ash the sdk for their CI etc, so we are keeping the old behavour for their dev flow).	2025-06-04 18:11:45 +12:00
Daniel Frederico Lins Leite	cee6f4e0e0	Const generics for "string array" and len methods (#7202) ... ## Description This PR is part of https://github.com/FuelLabs/sway/issues/6860. It implements "const generics" for "string arrays" and `len` methods for arrays and string arrays. ```sway #[cfg(experimental_const_generics = true)] impl<const N: u64> str[N] { pub fn len(self) -> u64 { N } } ```` ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: Joshua Batty <joshpbatty@gmail.com> Co-authored-by: IGI-111 <igi-111@protonmail.com>	2025-06-02 20:20:09 +10:00
zees-dev	a2f88d041c	feat: forc call tracing (#7196) ... ## Description Resolves https://github.com/FuelLabs/sway/issues/6706 Introduces `forc-call` transaction tracing - for verbosity levels `3+` (`-v=3` or `-vvv`). The tracing primarily utilizes transaction receipts, generating a call tree structure, then rendering this tree to `stdout`. Example usage output: ```sh > forc-call --abi ./demo/demo-caller/out/release/demo-caller-abi.json 9275a76531bce733cfafdbcb6727ea533ebbdc358d685152169b3c4eaa47b965 call_increment_count -vvv ``` <img width="629" alt="image" src="https://github.com/user-attachments/assets/6ad73c2a-a08e-4829-8d46-0b951e9b723b" /> <details> <summary>Output receipts for the trace above</summary> ```json { "receipts": [ { "Call": { "id": "0000000000000000000000000000000000000000000000000000000000000000", "to": "9275a76531bce733cfafdbcb6727ea533ebbdc358d685152169b3c4eaa47b965", "amount": 0, "asset_id": "f8f8b6283d7fa5b672b530cbb84fcccb4ff8dc40f8176ef4544ddb1f1952ad07", "gas": 124116, "param1": 10480, "param2": 10508, "pc": 11928, "is": 11928 } }, { "Call": { "id": "9275a76531bce733cfafdbcb6727ea533ebbdc358d685152169b3c4eaa47b965", "to": "b792b1e233a2c06bccec611711acc3bb61bdcb28f16abdde86d1478ee02f6e42", "amount": 0, "asset_id": "0000000000000000000000000000000000000000000000000000000000000000", "gas": 111500, "param1": 67107840, "param2": 67106816, "pc": 19064, "is": 19064 } }, { "ReturnData": { "id": "b792b1e233a2c06bccec611711acc3bb61bdcb28f16abdde86d1478ee02f6e42", "ptr": 0, "len": 0, "digest": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", "pc": 21004, "is": 19064, "data": [] } }, { "LogData": { "id": "9275a76531bce733cfafdbcb6727ea533ebbdc358d685152169b3c4eaa47b965", "ra": 0, "rb": 10098701174489624218, "ptr": 67104256, "len": 25, "digest": "392232ec5cf9a0ef3c155ad19684907344847572e913a7a374d703fb9c9d8b5d", "pc": 15804, "is": 11928, "data": [ 0, 0, 0, 0, 0, 0, 0, 17, 105, 110, 99, 114, 101, 109, 101, 110, 116, 101, 100, 32, 99, 111, 117, 110, 116 ] } }, { "Call": { "id": "9275a76531bce733cfafdbcb6727ea533ebbdc358d685152169b3c4eaa47b965", "to": "b792b1e233a2c06bccec611711acc3bb61bdcb28f16abdde86d1478ee02f6e42", "amount": 0, "asset_id": "0000000000000000000000000000000000000000000000000000000000000000", "gas": 86284, "param1": 67103232, "param2": 67102208, "pc": 19072, "is": 19072 } }, { "ReturnData": { "id": "b792b1e233a2c06bccec611711acc3bb61bdcb28f16abdde86d1478ee02f6e42", "ptr": 67099904, "len": 8, "digest": "cd04a4754498e06db5a13c5f371f1f04ff6d2470f24aa9bd886540e5dce77f70", "pc": 21352, "is": 19072, "data": [ 0, 0, 0, 0, 0, 0, 0, 2 ] } }, { "LogData": { "id": "9275a76531bce733cfafdbcb6727ea533ebbdc358d685152169b3c4eaa47b965", "ra": 0, "rb": 1515152261580153489, "ptr": 67098880, "len": 8, "digest": "cd04a4754498e06db5a13c5f371f1f04ff6d2470f24aa9bd886540e5dce77f70", "pc": 15976, "is": 11928, "data": [ 0, 0, 0, 0, 0, 0, 0, 2 ] } }, { "LogData": { "id": "9275a76531bce733cfafdbcb6727ea533ebbdc358d685152169b3c4eaa47b965", "ra": 0, "rb": 10098701174489624218, "ptr": 67097856, "len": 12, "digest": "a3d2743e2a3ab241ba31ffc7133a43daabe6a8e624c7edc92410068a3896c871", "pc": 16072, "is": 11928, "data": [ 0, 0, 0, 0, 0, 0, 0, 4, 100, 111, 110, 101 ] } }, { "Call": { "id": "9275a76531bce733cfafdbcb6727ea533ebbdc358d685152169b3c4eaa47b965", "to": "b792b1e233a2c06bccec611711acc3bb61bdcb28f16abdde86d1478ee02f6e42", "amount": 0, "asset_id": "0000000000000000000000000000000000000000000000000000000000000000", "gas": 72699, "param1": 67096832, "param2": 67095808, "pc": 19064, "is": 19064 } }, { "ReturnData": { "id": "b792b1e233a2c06bccec611711acc3bb61bdcb28f16abdde86d1478ee02f6e42", "ptr": 0, "len": 0, "digest": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", "pc": 21004, "is": 19064, "data": [] } }, { "Call": { "id": "9275a76531bce733cfafdbcb6727ea533ebbdc358d685152169b3c4eaa47b965", "to": "b792b1e233a2c06bccec611711acc3bb61bdcb28f16abdde86d1478ee02f6e42", "amount": 0, "asset_id": "0000000000000000000000000000000000000000000000000000000000000000", "gas": 48287, "param1": 67093248, "param2": 67092224, "pc": 19072, "is": 19072 } }, { "ReturnData": { "id": "b792b1e233a2c06bccec611711acc3bb61bdcb28f16abdde86d1478ee02f6e42", "ptr": 67089920, "len": 8, "digest": "d5688a52d55a02ec4aea5ec1eadfffe1c9e0ee6a4ddbe2377f98326d42dfc975", "pc": 21352, "is": 19072, "data": [ 0, 0, 0, 0, 0, 0, 0, 3 ] } }, { "ReturnData": { "id": "9275a76531bce733cfafdbcb6727ea533ebbdc358d685152169b3c4eaa47b965", "ptr": 67088896, "len": 8, "digest": "d5688a52d55a02ec4aea5ec1eadfffe1c9e0ee6a4ddbe2377f98326d42dfc975", "pc": 12608, "is": 11928, "data": [ 0, 0, 0, 0, 0, 0, 0, 3 ] } }, { "Return": { "id": "0000000000000000000000000000000000000000000000000000000000000000", "val": 1, "pc": 10388, "is": 10368 } }, { "ScriptResult": { "result": "Success", "gas_used": 89279 } } ] } ``` </details> --- The tracing is inspired by transaction trace provided by `cast run <tx-hash>` tool from foundry. Example usage/output of `cast run`: <img width="711" alt="image" src="https://github.com/user-attachments/assets/ad403c45-8944-4e26-95c3-a6804ef62fe3" /> --- ## Copilot Description This pull request introduces changes to the `forc-call` CLI, focusing on: - improving ABI handling - error reporting - transaction processing It refactors the `call_function` and `transfer` operations, introduces new structures for ABI management, and enhances the verbosity options for debugging transaction outputs. ### Enhancements to ABI Handling: * Introduced a new `Abi` struct to encapsulate `ProgramABI`, `UnifiedProgramABI`, and a type lookup map, simplifying ABI parsing and usage (`forc-plugins/forc-client/src/op/call/mod.rs`). * Updated `call_function` to use the new `Abi` struct and refactored ABI parsing to improve error handling during contract function calls (`forc-plugins/forc-client/src/op/call/call_function.rs`) [[1]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeL49-R62) [[2]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeL213-R245). ### Improvements in Transaction Processing: * Enhanced the `process_transaction_output` function to include `CallData` for better handling of ABI and contract-related data. Also, added support for printing transaction traces and logs with higher verbosity levels (`forc-plugins/forc-client/src/op/call/mod.rs`). * Refactored receipt handling in `call_function` to include detailed error reporting and optional ABI mappings for debugging (`forc-plugins/forc-client/src/op/call/call_function.rs`). ### Code Simplification and Refactoring: * Removed redundant `ProgramABI` usage in the `transfer` function and updated it to use the new transaction processing logic (`forc-plugins/forc-client/src/op/call/transfer.rs`). * Consolidated imports and removed unused dependencies across multiple files to streamline the codebase (`forc-plugins/forc-client/src/op/call/call_function.rs`, `forc-plugins/forc-client/src/op/call/mod.rs`, `forc-plugins/forc-client/src/op/call/transfer.rs`) [[1]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeL6-R18) [[2]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeL32-R33) [[3]](diffhunk://#diff-6b8144a652cd418525566ff9da96c87495dd239934e78788f2f79422657e5960L2-L8). ### Enhanced Debugging and Verbosity: * Added a new `print_receipts_and_trace` function to format and display transaction receipts and traces based on verbosity levels, aiding in debugging complex transactions (`forc-plugins/forc-client/src/op/call/mod.rs`). * Renamed `script` to `script_json` in `CallResponse` for clarity and consistency with JSON output conventions (`forc-plugins/forc-client/src/op/call/mod.rs`). ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: z <zees-dev@users.noreply.github.com> Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2025-05-30 03:00:17 +00:00
kaya	c0b6dea2d9	feat: more descriptive publish error message for forc-publish (#7208) ... ## Description closes #7207. Adding the underlying error message to `thiserror` impls in forc-publish so that we can debug things easier.	2025-05-30 14:40:07 +12:00
Igor Rončević	f03d5ecdb0	Compile panic expression to ABI error codes (#7118) ... ## Description This PR is the final step in implementing the `panic` expression and the ABI errors, as defined in the [ABI Errors RFC](https://github.com/FuelLabs/sway-rfcs/blob/master/rfcs/0014-abi-errors.md). The PR generates the `errorCodes` section in the ABI, like, e.g.: ``` "errorCodes": { "18446744069414584320": { "pos": { "pkg": "my_lib@1.2.3", "file": "src/lib.rs", "line": 42, "column": 13 }, "logId": null, "msg": "Error message." }, "18446744069414584321": { "pos": { "pkg": "my_contract", "file": "src/main.rs", "line": 21, "column": 34 }, "logId": "4933727799282657266", "msg": null } } ``` If the `panic` argument is a string slice that can be const-evaluated, the `msg` field of the corresponding error code is generated, and a log is not emitted. The string itself is stored only within the ABI JSON, and is not included into the generated bytecode. Additionally, the PR: - provides a common infrastructure for obtaining a `SourceLocation` from a `Span`. This is currently used in the implementation of the `__dbg` intrinsics and the `panic` expression. - improves filtering of `forc` outputs in snapshot tests by supporting regular expressions. The `grep` command is renamed to `regex` to avoid confusion with piping the actual `grep` CLI command. Partially addresses #6765. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: hal3e <git@hal3e.io>	2025-05-27 20:32:40 +10:00
kaya	c8625a029c	fix: ensure forc-node ignition fetches ignition chain config (#7194) ... ## Description closes #7193. There was a simple bug in the mainnet setup we were still fetching testnet configuration. Which caused some syncing issues.	2025-05-23 14:08:38 +12:00
Sophie Dankel	e3eab78454	feat: use SSE in forc-publish for long-running uploads (#7178) ... This pull request introduces changes to enhance the functionality of the `forc-publish` plugin, including improvements to error handling, support for streaming server responses, and updates to dependencies. The most significant changes include adding a new error variant, updating the `upload` method to handle streaming responses, and modifying dependencies to include `futures-util` and additional features for `reqwest`. ### Enhancements to Error Handling: * Added a new `ServerError` variant to the `Error` enum in `forc-plugins/forc-publish/src/error.rs` to handle server-related errors. ### Improvements to `upload` Method: * Updated the `upload` method in `forc-publish/src/forc_pub_client.rs` to process streaming server responses using `futures-util::StreamExt`. This includes handling chunked data, parsing JSON responses, and printing event updates. [[1]](diffhunk://#diff-c706a808124a73081593a5e34fb999aa1a446f97d97da1657ddb4b3c55d24371R43) [[2]](diffhunk://#diff-c706a808124a73081593a5e34fb999aa1a446f97d97da1657ddb4b3c55d24371L53-R97) ### Dependency Updates: * Added `futures-util` as a dependency in `Cargo.toml` and `forc-plugins/forc-publish/Cargo.toml` to support streaming operations. [[1]](diffhunk://#diff-2e9d962a08321605940b5a657135052fbcef87b5e360662bb527c96d9a615542R157) [[2]](diffhunk://#diff-2bd34a7b1fa0f1850ad25c6e080d410b2df98c16b6cd75445a138d04e617311aL16-R17) * Enabled the `stream` feature for `reqwest` in `forc-plugins/forc-publish/Cargo.toml` to facilitate streaming server responses. ### Minor Adjustments: * Added empty `println!` calls in `main.rs` to improve output formatting during error handling and publishing operations. [[1]](diffhunk://#diff-2c9e261f1e02238f33a9403387f40481b5b372475c0de3782146b614210675b3R32) [[2]](diffhunk://#diff-2c9e261f1e02238f33a9403387f40481b5b372475c0de3782146b614210675b3R52) 	2025-05-20 06:18:57 -07:00
Sophie Dankel	0e3d949dbf	chore: move test deps to dev-dependencies (#7181) ... ## Description I noticed that some test dependencies were being included in builds unnecessarily. This PR moves them to dev-dependencies. ## Checklist - [ ] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers.	2025-05-17 14:26:25 +12:00
Sophie Dankel	aafcdc868d	fix: Print full error in forc-publish (#7173) ... ## Description ## Checklist - [ ] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers.	2025-05-14 05:34:41 +00: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
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
zees-dev	dffa29c599	feat: forc call json output (#7156) ... ## Description This PR adds JSON output support for `forc-call` CLI. Additionally, it adds JSON support for `tracing-subscriber` in `forc-tracing` - with option to omit logs from other libraries (via regex). - JSON tracing-subscriber ignores colored output - Forc-call hooks into this tracing-subscriber (using `Json` variant) to output JSON response ### Changelog This pull request introduces enhancements to the `forc-call` plugin, focusing on improving output formatting, streamlining verbosity handling, and updating test cases to reflect these changes. The most significant updates include the addition of a JSON output format, the removal of the `Verbosity` struct, and modifications to test cases to handle optional results. ### Output Formatting Enhancements: * Added a new `Json` variant to the `OutputFormat` enum for outputting full tracing information in JSON format. Implemented the `Write` trait for `OutputFormat` to handle different output styles. (`forc-plugins/forc-client/src/cmd/call.rs`, [forc-plugins/forc-client/src/cmd/call.rsR60-R87](diffhunk://#diff-466e2f9659cab303594eb73a846768ecdbc1a13030e5869cdac51ddde87dd313R60-R87)) * Updated the `Command` struct to include a short option (`-o`) for specifying the output format. (`forc-plugins/forc-client/src/cmd/call.rs`, [forc-plugins/forc-client/src/cmd/call.rsL319-R319](diffhunk://#diff-466e2f9659cab303594eb73a846768ecdbc1a13030e5869cdac51ddde87dd313L319-R319)) ### Verbosity Handling Simplification: * Removed the `Verbosity` struct and its associated methods. Verbosity is now directly represented as an integer (`cmd.verbosity`) for simplicity. (`forc-plugins/forc-client/src/cmd/call.rs`, [[1]](diffhunk://#diff-466e2f9659cab303594eb73a846768ecdbc1a13030e5869cdac51ddde87dd313R60-R87); `forc-plugins/forc-client/src/op/call/call_function.rs`, [[2]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeL2-R2) [[3]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeL54-L57) [[4]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeL181-R185) [[5]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeL216-R227) ### Test Case Updates: * Modified test cases to handle optional results by calling `.unwrap()` on the `result` field where applicable. This ensures compatibility with changes to how results are processed. (`forc-plugins/forc-client/src/op/call/call_function.rs`, [[1]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeL356-R387) through [[2]](diffhunk://#diff-7da99987eeed69f070b781a5692d3acc7028308b8538ca129d79452ccc057fdeL661-R710) These changes improve the usability and maintainability of the `forc-call` plugin, making it more robust and user-friendly. Note: This is a pre-requisite to resolve https://github.com/FuelLabs/sway/issues/7019; the output script in the JSON can be directly parsed into a `tx.json` file for `forc-debug`. ## Checklist - [ ] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: z <zees-dev@users.noreply.github.com>	2025-05-09 20:07:27 +12:00
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
zees-dev	66c9c1f856	sway-book: fix forc call examples (#7133) ... ## Description This pull request introduces updates to the documentation and examples for the `forc call` command, improving clarity, organization, and usability. The most significant changes include restructuring the documentation into a new file, updating the book summary to reflect this change, and enhancing the examples in the codebase for better readability. Added dedicated section for `forc-call` under testing heading. <img width="1309" alt="image" src="https://github.com/user-attachments/assets/446f6846-e294-472c-9e71-a3f1192960c5" /> ### Documentation Updates: * **New Documentation File for `forc call`**: The detailed documentation for the `forc call` command has been moved to a new file, `docs/book/src/forc/plugins/forc_client/forc_call_docs.md`. This includes comprehensive usage examples, parameter encoding details, and troubleshooting tips. * **Removal of Old Documentation**: The old `forc_call.md` file has been removed, as its content has been migrated to the new structured format. ### Book Summary Update: * **Updated `SUMMARY.md`**: The book summary has been updated to include a link to the new `forc call` documentation under the "Testing" section for better navigation. ### Code Example Enhancements: * **Improved Examples in `call.rs`**: Examples in the `forc call` command's code file (`forc-plugins/forc-client/src/cmd/call.rs`) have been reformatted for clarity. Each example now uses markdown-style code blocks and descriptive headings, making them easier to follow. ## 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: Sophie Dankel <47993817+sdankel@users.noreply.github.com> Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2025-05-02 16:27:47 +12: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
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
Daniel Frederico Lins Leite	26e2ef875c	Support for const generics in structs (#7076) ... ## Description Part of https://github.com/FuelLabs/sway/issues/6860. This PR enables code like below to be written now. This will allow the implementation of `iter()` for arrays. ```sway struct S<T, const N: u64> {} impl<T, const N: u64> S<T, N> { pub fn len_xxx(self) -> u64 { N } } ``` Limited to `structs` now. `enum` will be implemented in a future PR. ## 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. --------- Co-authored-by: IGI-111 <igi-111@protonmail.com>	2025-04-29 19:16:48 -03:00
Igor Rončević	76268dcff7	Add support for experimental features in the parsing phase (#7124) ... ## Description This PR brings support for experimental features to the parsing phase. This is needed so that we can support use cases like, e.g., adding new language keywords behind a feature flag. A concrete example would be the `panic` keyword added in #7073. The parsing of the `panic` token differs if it is interpreted as a keyword (when the `error_type` experimental feature is active) or as a regular identifier (when `error_type` is off). Because `ExperimentalFeatures` are needed in the `Parse::parse(parser: &mut Parser)` methods, the `Parser` got extended with the `experimental` field. The consequence of bringing the `ExperimentalFeatures` to the parsing phase is, that `swayfmt` and `forc fmt` can also require an experimental feature to be set, to properly parse a project. In those tools, `ExperimentalFeatures` are passed as a field on the `Formatter`. Note that this PR does not put the provided experimental flags into use. The first concrete usage will be in #7073. This PR is a prerequisite for #7073. ## 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-04-29 11:36:37 +12:00
zees-dev	5f999595d3	forc-call: missing contract retrieval refactor (#7115) ... ## Description Using `fuels-rs` SDK to retrieve missing contracts for a forc-call query. This function/improvement was introduced in the `fuels-rs` sdk here: https://github.com/FuelLabs/fuels-rs/pull/1628 Addresses: https://github.com/FuelLabs/sway/issues/7113 ## Checklist - [x] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers. Co-authored-by: z <zees-dev@users.noreply.github.com> Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2025-04-24 05:31:23 +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
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
João Matos	3afc5c18c8	Improved trait coherence checking (#6844) ... ## Description This PR refines trait coherence checking to guarantee that there is only one valid implementation for each trait. It introduces improved orphan rules and more rigorous overlap checks to prevent conflicting trait implementations. With these changes, the system now more reliably enforces coherence, ensuring that traits are implemented uniquely, and reducing potential ambiguities. This approach mirrors Rust’s design by enforcing two distinct safety and coherence checks on trait implementations: **1. Orphan Rules Check** The orphan rules require that for any trait implementation, either the trait or the type must be defined within the current package. This restriction prevents external packages from implementing foreign traits for foreign types, which could otherwise lead to conflicting implementations and ambiguities across different parts of a codebase. Essentially, it helps maintain clear ownership and boundaries of trait implementations. **2. Overlap Impl Check** The overlap impl check ensures that no two trait implementations can apply to the same type in an ambiguous manner. If two implementations could potentially match the same type, it would be unclear which one should be used, leading to coherence issues. By enforcing that implementations do not overlap, the system guarantees that trait resolution is unambiguous and predictable. Together, these checks promote a robust and maintainable system by ensuring that trait implementations are both locally controlled (orphan rules) and non-conflicting (overlap check). The test suite has been updated to comply with the new rules. However, there is one current limitation regarding arrays. For arrays, the coherence checks have been relaxed to avoid the need for numerous concrete implementations in the standard library for traits like `Eq` and `PartialEq`. This decision was made because support for const generics is expected soon, which will allow these traits to be implemented more cleanly. Closes issue https://github.com/FuelLabs/sway/issues/5892. ## 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.	2025-04-17 22:57:45 +01:00