517 commits

Author	SHA1	Message	Date
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
MozirDmitriy	32dcbaa243	docs: fix broken sway-libs GitHub link to use official documentation URL (#7298) ... - Replace https://github.com/FuelLabs/sway-libs/tree/master/libs/src/ownership with https://fuellabs.github.io/sway-libs/book/ownership/index.html	2025-07-28 19:51:33 -07: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
João Matos	f117e855ea	Add #[abi_name(name = "foo")] attribute to rename ABI items. (#7057) ... ## Description Add `#[abi_name(name = "foo")]` attribute to rename enum and struct ABI items. Here is example of how it can be used: ```sway contract; #[abi_name(name = "RenamedMyStruct")] struct MyStruct {} #[abi_name(name = "RenamedMyEnum")] enum MyEnum { A: () } abi MyAbi { fn my_struct() -> MyStruct; fn my_enum() -> MyEnum; } impl MyAbi for Contract { fn my_struct() -> MyStruct { MyStruct{} } fn my_enum() -> MyEnum { MyEnum::A } } ``` Closes https://github.com/FuelLabs/sway/issues/5955. ## Remarks The checking for ABI names is being done in the ABI generation phase, which made it a requirement to change the interface of ABI checking to return Results everywhere and passing Handler all the way down, so emitted errors can be passed down to the driver for reporting. ## 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: IGI-111 <igi-111@protonmail.com>	2025-07-17 20:12:36 -07:00
Daniel Frederico Lins Leite	384f46f61d	Contract self impl (#7275) ... ## Description Continuation of https://github.com/FuelLabs/sway/pull/7030. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: hey-ewan <ewanretorokugbe@gmail.com> Co-authored-by: ewan ✦ <66304707+hey-ewan@users.noreply.github.com> Co-authored-by: IGI-111 <igi-111@protonmail.com>	2025-07-11 11:02:37 +00:00
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
Joshua Batty	c37dc92952	remove archived forc-explore plugin from CI and docs (#7257) ... ## Description This repo was [archived ](https://github.com/FuelLabs/forc-explorer )in July 2024 but was not removed from CI or the docs. I have update the plugins section of the documentation from forc explore to `forc-install` which is a [tool](https://github.com/DarthBenro008/forc-install) from a community member. ## Checklist - [x] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-06-27 12:53:25 +00:00
Vaivaswatha N	586a968ef1	support __addr_of for all types (#7255)	2025-06-27 15:33:42 +12:00
Igor Rončević	3b5e7a8d9b	Add docs for error handling (ABI errors, panic, error_type, error) (#7249) ... ## Description This PR: - Adds a new "Error handling" page to "Sway Language Basics". - Updates all references to ABI errors. - Extends the "Breaking Release Checklist" with documentation related checks. ## 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). - [x] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-06-23 13:15:50 +00:00
VolodymyrBg	83154ab661	Update Merkle library link to current documentation (#7244) ... Replaced the outdated GitHub link to the Binary Merkle Proof library with the up-to-date documentation link at https://docs.fuel.network/docs/sway-libs/merkle/. This ensures users have access to the latest usage instructions and examples.	2025-06-22 03:43:10 +04:00
Cameron Carstens	d6804729c9	Introduce the Time Library (#7206) ... ## Description This PR introduces a comprehensive UNIX time handling library to the Sway standard library, providing essential time manipulation capabilities for smart contracts. Time operations are fundamental for many smart contract use cases: - Token vesting schedules - Auction deadlines - Time-locked transactions - Subscription renewals - Staking periods Currently, Sway lacks standardized time utilities, forcing developers to: - Handle time conversions manually - Implement custom time logic in every contract - Risk errors in critical time calculations This library solves these problems with a robust, well-tested time abstraction. ### Duration Handling ```sway // Create durations using natural units let lock_period = Duration::days(90); let auction_extension = Duration::minutes(15); // Convert between units log(lock_period.as_weeks()); // ≈12.857 weeks log(auction_extension.as_seconds()); // 900 seconds // Duration arithmetic let total_lock = lock_period + Duration::weeks(2); ``` ### Blockchain Time Operations ```sway // Get current block time let now = Time::now(); // Create future/past timestamps let unlock_time = now.add(Duration::days(30)); let vesting_start = now.subtract(Duration::weeks(12)); // Measure time differences let time_elapsed = now.duration_since(vesting_start).unwrap(); ``` ### TAI64 ↔ UNIX Conversion Support for the existing TAI64 `timestamp()` functionality is maintained. ```sway // Native TAI64 from blockchain let tai_timestamp = timestamp(); // Convert to UNIX time let unix_time = Time::from_tai64(tai_timestamp); // Convert back to TAI64 let converted_tai = unix_time.as_tai64(); assert(tai_timestamp == converted_tai); ``` ### Benefits - Safety: Prevents common time calculation errors - Accuracy: Properly handles TAI64/UNIX conversion - Productivity: Reduces boilerplate for time operations - Consistency: Standardized approach across contracts - Readability: Natural time unit expressions ### Future Extensions Once support between different types for `Add`, `Subtract`, `Multiply`, etc are implemented, we may be able to do the following: ```sway let now = Time::now(); let future = now + Duration::DAY; let three_weeks = Duration::WEEK * 3; ``` Closes https://github.com/FuelLabs/sway/issues/3945 ## 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-05-30 19:03:23 +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
BlockyJ	ee565f9145	feat: implement forc add and forc remove to add/remove dependencies (#7143) ... ## Description Close #2369 **Summary:** Implements functionality for `forc` to add remove dependencies through cli, similar to Cargo's `add` and `remove` commands. **Work Done:** * ✅ Added `forc add` command to support adding both regular and contract dependencies from path, git, IPFS, or version. * ✅ Implemented conflict checks for version + source collisions (e.g., version + git). * ✅ Added automatic fallback to workspace-relative path for local packages. * ✅ Introduced `forc remove` to cleanly remove specified dependencies from the manifest. * ✅ Modularized update logic using `DepSection` enum for unified regular/contract dependency handling. * ✅ Used `toml_edit` to update the manifest file while preserving formatting. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-05-21 23:47:46 -07:00
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
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	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
kaya	ba3a0d5635	feat: registry source resolution and builds (#7038) ... ## Description closes #3752, #6903. Adds registry source resolutions and support for building.	2025-04-09 21:09:47 -07:00
Igor Rončević	c25c5af2da	Add #[error_type] and #[error] attributes (#7058) ... ## Description This PR adds `#[error_type]` and `#[error]` attributes to the collection of known attributes, as defined in the [ABI Errors RFC](https://github.com/FuelLabs/sway-rfcs/blob/master/rfcs/0014-abi-errors.md). Additionally, the PR updates the outdated documentation for _Attributes_ and _Keywords_. Partially addresses #6765. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-04-07 09:37:04 +00:00
zees-dev	d6410e37f0	Forc call transfers (#7056) ... ## Description Implementation of direct transfer of assets to an address using `forc-call` binary. Refactor of the `forc-call` binary since it now supports 3 code paths: - calling (query or tx submission) contracts - transferring assets directly to an address (recipient and/or contract) - listing contract functions with call examples ## Usage ```sh # transfer default asset (eth) to `0x2c7Fd852EF2BaE281e90ccaDf18510701989469f7fc4b042F779b58a39919Eec` forc-call 0x2c7Fd852EF2BaE281e90ccaDf18510701989469f7fc4b042F779b58a39919Eec --amount 2 --mode=live ``` ### Output ```log warning: No signing key or wallet flag provided. Using default signer: 0x6b63804cfbf9856e68e5b6e7aef238dc8311ec55bec04df774003a2c96e0418e Transferring 2 0xf8f8b6283d7fa5b672b530cbb84fcccb4ff8dc40f8176ef4544ddb1f1952ad07 to recipient address 0x2c7fd852ef2bae281e90ccadf18510701989469f7fc4b042f779b58a39919eec... tx hash: e4e931276a500cce1b5303cb594c0477968124ab0f70e77995bbb4499e0c3350 ``` ## Additional notes - Inspired by `cast send` where if the CLI is called without a function signature, it transfers value (eth) to the target address based on the `--value` parameter; `forc-call` does the same via the `--amount` param - One can specify the `asset` to be sent; defaults to native network asset (`eth`) - Transfers only work with `--mode=live`; since there is no simulation/dry-run functionality available for this - Transfers to both contracts and user recipients is supported ## 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. --------- Co-authored-by: z <zees-dev@users.noreply.github.com> Co-authored-by: kaya <kaya.gokalp@fuel.sh> Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2025-04-06 23:38:47 -07:00
Igor Rončević	74282e2c7b	Defining, parsing, and checking #[attribute]s (#6986) ... ## Description This PR reimplements how `#[attribute]`s are parsed, defined, and checked. It fixes the following issues we had with attributes: - attributes were in general not checked for their expected and allowed usage. - when checked, checks were fixing particular reported issues and were scattered through various compilation phases: lexing, parsing, and tree conversion. - when checked, reported errors in some cases had bugs and were overalapping with other errors and warnings. - attribute handling was not centralized, but rahter scattered throught the whole code base, and mostly done at use sites. For concrete examples of these issues, see the list of closed issues below. The PR: - encapsulates the attributes handling within a single abstraction: `Attributes`. - assigns the following properties to every attribute: - _target_: what kind of elements an attribute can annotate. - _multiplicity_: if more then one attribute of the same kind can be applied to an element. - _arguments multiplicity_: a range defining how many arguments an attribute can or must have. - _arguments value expectation_: if attribute arguments are expected to have values. - validates those properties in a single place, during the `convert_parse_tree`. Note that this means that modules with attribute issues will now consistently not reach the type checking phase. This was previously the case for some of the issues with attributes where custom checks where done during the type checking phase. #6987 proposes to move those checks after the tree conversion phase, allowing the continuation of compilation. - adds the `AttributeKind::Unknow` to preserve unknown attributes in the typed tree. - removes redundant code related to attributes: specific warnings and errors, specialized parsing, repetitive and error-prone at use site checks, etc. - removes the unused `Doc` attribute. The PR also introduces a new pattern in emitting errors. The `attr_decls_to_attributes` function will always return `Attributes` even if they have errors, because: - we expect the compilation to continue even in the case of errors. - we expect those errors to be ignored if a valid `#[cfg]` attribute among those evaluates to false. - we expect them to be emitted with eventual other errors, or alone, at the end of the tree conversion of the annotated element. For more details, see the comment on `attr_decls_to_attributes` and `cfg_eval`. Closes #6880; closes #6913; closes #6914; closes #6915; closes #6916; closes #6917; closes #6918; closes #6931; closes #6981; closes #6983; closes #6984; closes #6985. ## Breaking changes Strictly seen, this PR can cause breaking changes, but only in the case of invalid existing attribute usage. We treat those breaking changes as bug fixes in the compiler and, thus, do not have them behind a feature flag. E.g., this kind of code was possible before, but will now emit and error: ```sway #[storage(read, write, read, write)] struct Struct {} ``` ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-03-24 09:34:31 +11:00
zees-dev	6cd732b56e	forc-call list functions support with example call usage (#7018) ... ## Description Adds optional `--list-functions` CLI arg to `forc call`. With provided ABI and a contract address; calling `forc-call` with `--list-functions` will list all available functions in the contract and additionally display example CLI usage to call the respective functions with default/basic parameters. ## Example output ```sh > forc call -- \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 --list-functions Available functions in contract: 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 test_array(a: [u64; 10]) -> [u64; 10] forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_array "[0, 0, 0, 0, 0, 0, 0, 0, 0, 0]" test_b256(a: b256) -> b256 forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_b256 "0x0000000000000000000000000000000000000000000000000000000000000000" test_bytes(a: Bytes) -> Bytes forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_bytes "0x" test_complex_struct(a: ComplexStruct) -> ComplexStruct forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_complex_struct "{({aa, 0}, 0), (Active:false), 0, {{0, aaaa}, aaaa}}" test_empty() -> () forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_empty test_empty_no_return() -> () forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_empty_no_return test_enum(a: Status) -> Status forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_enum "(Active:false)" test_enum_with_complex_generic(a: GenericEnum) -> GenericEnum forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_enum_with_complex_generic "(container:{{0, aaaa}, aaaa})" test_enum_with_generic(a: GenericEnum) -> GenericEnum forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_enum_with_generic "(container:{0, aaaa})" test_option(a: Option) -> Option forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_option "(None:())" test_str(a: str) -> str forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_str "hello" test_str_array(a: str[10]) -> str[10] forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_str_array "aaaaaaaaaa" test_str_slice(a: str) -> str forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_str_slice "hello" test_struct(a: User) -> User forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_struct "{aa, 0}" test_struct_with_generic(a: GenericStruct) -> GenericStruct forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_struct_with_generic "{0, aaaa}" test_tuple(a: (u64, bool)) -> (u64, bool) forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_tuple "(0, false)" test_u128(a: U128) -> U128 forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_u128 "0" test_u16(a: u16) -> u16 forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_u16 "0" test_u256(a: U256) -> U256 forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_u256 "0" test_u32(a: u32) -> u32 forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_u32 "0" test_u64(a: u64) -> u64 forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_u64 "0" test_u8(a: u8) -> u8 forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_u8 "0" test_unit(a: ()) -> () forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_unit "()" test_vector(a: Vec<u64>) -> Vec<u64> forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ test_vector "[0, 0]" transfer(amount_to_transfer: u64, asset_id: AssetId, recipient: Identity) -> () forc call \ --abi ./forc-plugins/forc-client/test/data/contract_with_types/contract_with_types-abi.json \ 23190a0648a92ac42f58dc2f4159ee28cdd1448bbcaabd272ec42a00e8e4aed4 \ transfer "0" "{0x0000000000000000000000000000000000000000000000000000000000000000}" "(Address:{0x0000000000000000000000000000000000000000000000000000000000000000})" ``` Addresses https://github.com/FuelLabs/sway/issues/6935 ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] 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-03-18 15:09:10 +13:00
Igor Rončević	58114d7e68	Promote experimental features (#7016) ... ## Description This PR promotes the following experimental features to standard ones: - #6701 - #6883 - #6994 - #7006 Additionally, the PR stenghtens the migration infrastructure by checking some additional cases in selecting corresponding typed elements in desugared code which were not checked before. Closes #6701. Closes #6883. Closes #6994. Closes #7006. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-03-13 20:47:01 +11:00
SwayStar123	a5d9d2835f	Merge std and core libraries (#6729) ... ## Description Merges the two libraries. They were initially separate to separate the core logic and fuel vm specific functionality, but that separation is no longer maintained so having a merged library is better. Closes #6708 ## Checklist - [ ] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: Sophie <47993817+sdankel@users.noreply.github.com> Co-authored-by: Igor Rončević <ironcev@hotmail.com>	2025-03-12 23:52:38 +01:00
Igor Rončević	74b724da20	Add "Breaking Release Checklist" to internal docs (#6980) ... ## Description This PR adds the first version of the "Breaking Release Checklist" document to the compiler's internal documentation. ## Checklist - [ ] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-03-04 11:16:51 +01:00
Sophie Dankel	d00c0fe44d	feat: Support categories and keywords in forc manifest (#6974) ... ## Description Related https://github.com/FuelLabs/forc.pub/issues/30 ## Checklist - [ ] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers.	2025-03-03 14:17:45 -08:00
zees-dev	20973803db	forc-call logs support (#6968) ... ## Description - Added support for viewing emitted logs when making a transaction using forc-call - Added `show_receipts` param (default-false) - so we can optionally prnt out all receipts - The CLI output becomes too long for a call with multiple receipts; this is a minor UI enhancement Addresses https://github.com/FuelLabs/sway/issues/6887 ## Example usage/output ```sway script; struct ExampleParams { test_val: u32, test_str: str, test_tuple: (u32, u64), } fn main() -> u64 { log("hiiii"); log(123); log(ExampleParams { test_val: 5, test_str: "hello world", test_tuple: (1,2) }); 5 } ``` <img width="986" alt="image" src="https://github.com/user-attachments/assets/3725ff17-29c9-43d7-98cc-4cacfc213ecb" /> ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: z <zees-dev@users.noreply.github.com> Co-authored-by: Joshua Batty <joshpbatty@gmail.com> Co-authored-by: kayagokalp <kayagokalp123@gmail.com>	2025-03-01 14:26:16 +13:00
Kaya Gökalp	15899514eb	feat: add forc-node command for easily bootstrapping a node (#6473)	2025-02-15 12:34:45 +11:00
zees-dev	696cb57883	minor: Migrate forc-call node_url (#6920) ... ## Description Migrated the `node_url` function; addressing the todo. Also refactored the function to ease readability and maintainability. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: z <zees-dev@users.noreply.github.com>	2025-02-14 15:01:28 +13:00
Igor Rončević	1270bfa53f	Marker traits (#6871) ... ## Description This PR introduces the concept of marker traits to the language. It is the first step towards implementing the [ABI errors RFC](https://github.com/FuelLabs/sway-rfcs/blob/master/rfcs/0014-abi-errors.md). Marker traits are traits automatically generated by the compiler. They represent certain properties of types and cannot be explicitly implemented by developers. The PR implements a common infrastructure for generating and type-checking marker traits as well as two concrete marker traits: - `Error`: represents a type whose instances can be used as arguments for the `panic` expression. (The `panic` expression is yet to be implemented.) - `Enum`: represents an enum type. Combining these two marker traits in trait constraints allow expressing constraints such is, e.g., "the error type must be an error enum": ``` fn panic_with_error<E>(err: E) where E: Error + Enum { panic err; } ``` Note that the generic name `Enum` is sometimes used in our tests to represent a dummy enum. In tests, it is almost always defined locally, and sometimes explicitly imported, so it will never clash with the `Enum` marker trait. A single test in which the clash occurred was easily adapted by explicitly importing the dummy `Enum`. The PR is the first step in implementing #6765. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-02-07 03:25:57 +00:00
zees-dev	0de1c32c22	plugin: forc-call (#6791) ... ## Description The following PR introduces a new forc plugin; `forc-call`. This plugin allows users to call functions on deployed contracts using the `forc call` command. This is ideal for quickly querying the state of a deployed contract. In this first implementation; the contract ABI is required (as a path to a local JSON file or a URL to a remote JSON file). This is inspired by the [`cast call`](https://book.getfoundry.sh/reference/cast/cast-call) tool; which is a popular tool for interacting with deployed contracts on Ethereum. The implementation is based on the following Github issue: https://github.com/FuelLabs/sway/issues/6725 In the current implementation, you can query a contract state using the `forc call` command by providing the target contract ID, it's respective ABI file, and the function name (selector) and arguments. <details> <summary>Forc Call CLI</summary> ```sh forc call --help ``` ``` Call a contract function Usage: forc call [OPTIONS] <CONTRACT_ID> <FUNCTION> [ARGS]... Arguments: <CONTRACT_ID> The contract ID to call <FUNCTION> The function signature to call. When ABI is provided, this should be a selector (e.g. "transfer") When no ABI is provided, this should be the full function signature (e.g. "transfer(address,u64)") [ARGS]... Arguments to pass into main function with forc run Options: --abi <ABI> Optional path or URI to a JSON ABI file --node-url <NODE_URL> The URL of the Fuel node to which we're submitting the transaction. If unspecified, checks the manifest's `network` table, then falls back to `http://127.0.0.1:4000` You can also use `--target`, `--testnet`, or `--mainnet` to specify the Fuel node. [env: FUEL_NODE_URL=] --target <TARGET> Use preset configurations for deploying to a specific target. You can also use `--node-url`, `--testnet`, or `--mainnet` to specify the Fuel node. Possible values are: [local, testnet, mainnet] --testnet Use preset configuration for testnet. You can also use `--node-url`, `--target`, or `--mainnet` to specify the Fuel node. --mainnet Use preset configuration for mainnet. You can also use `--node-url`, `--target`, or `--testnet` to specify the Fuel node. --signing-key <SIGNING_KEY> Derive an account from a secret key to make the call [env: SIGNING_KEY=] --wallet Use forc-wallet to make the call --amount <AMOUNT> Amount of native assets to forward with the call [default: 0] --asset-id <ASSET_ID> Asset ID to forward with the call --gas-forwarded <GAS_FORWARDED> Amount of gas to forward with the call --mode <MODE> The execution mode to use for the call; defaults to dry-run; possible values: dry-run, simulate, live [default: dry-run] --gas-price <PRICE> Gas price for the transaction --script-gas-limit <SCRIPT_GAS_LIMIT> Gas limit for the transaction --max-fee <MAX_FEE> Max fee for the transaction --tip <TIP> The tip for the transaction --external-contracts <EXTERNAL_CONTRACTS> The external contract addresses to use for the call If none are provided, the call will automatically extract contract addresses from the function arguments and use them for the call as external contracts -h, --help Print help (see a summary with '-h') -V, --version Print version ``` </details> ### Example usage ```sh forc call 0xe18de7c7c8c61a1c706dccb3533caa00ba5c11b5230da4428582abf1b6831b4d --abi ./out/debug/counter-contract-abi.json add 1 2 ``` - where `0xe18de7c7c8c61a1c706dccb3533caa00ba5c11b5230da4428582abf1b6831b4d` is the contract ID - where `./out/debug/counter-contract-abi.json` is the path to the ABI file - where `add` is the function name (selector) - where `1 2` are the arguments to the function ^ the sway code for the add function could be: ```sway contract; abi MyContract { fn add(a: u64, b: u64) -> u64; } impl MyContract for Contract { fn add(a: u64, b: u64) -> u64 { a + b } } ``` ## Implementation details 1. The provided ABI file downloaded (unless local path is provided) 2. The ABI is parsed into internal representation 3. The provided function selector e.g. `add` is matched with the extracted functions from the ABI 4. The provided arguments are parsed into the appropriate types which match the extracted function's inputs 5. The function selector and args are then converted into the `Token` enum, which is then ABI encoded as part of the `ContractCall` struct 6. The `ContractCall` struct is then used to make a request to the node to call the function 7. The response is then decoded into the appropriate type (based on matched function's output type) ^ In the implementation, we don't use the `abigen!` macro since this is a compile time parser of the ABI file; instead we make use of the lower level encoding and decoding primitives and functions from the [Rust SDK](https://github.com/FuelLabs/fuels-rs). ## Live example on testnet ### Example 1 The example contract above with `add` function has been deployed on testnet - with ABI file available [here](https://pastebin.com/raw/XY3awY3T). The add function can be called via the CLI: ```sh cargo run -p forc-client --bin call -- \ --testnet \ --abi https://pastebin.com/raw/XY3awY3T \ 0xe18de7c7c8c61a1c706dccb3533caa00ba5c11b5230da4428582abf1b6831b4d \ add 1 2 ``` ### Example 2 - get `owner` of Mira DEX contract ```sh cargo run -p forc-client --bin call -- \ --testnet \ --abi https://raw.githubusercontent.com/mira-amm/mira-v1-periphery/refs/heads/main/fixtures/mira-amm/mira_amm_contract-abi.json \ 0xd5a716d967a9137222219657d7877bd8c79c64e1edb5de9f2901c98ebe74da80 \ owner ``` Note: Testnet contract address [here](https://docs.mira.ly/developer-guides/developer-overview#testnet-deployment) ## Encoding of primitive types When passing in function arguments, the following types are encoded as follows: | Types | Example input | Notes | |-----------------------------------------------|----------------------------------------------------------------------|------------------------------------------------------------------------------------------------| | bool | `true` or `false` | | | u8, u16, u32, u64, u128, u256 | `42` | | | b256 | `0x0000000000000000000000000000000000000000000000000000000000000042` or `0000000000000000000000000000000000000000000000000000000000000042` | `0x` prefix is optional | | bytes, RawSlice | `0x42` or `42` | `0x` prefix is optional | | String, StringSlice, StringArray (Fixed-size) | `"abc"` | | | Tuple | `(42, true)` | The types in tuple can be different | | Array (Fixed-size), Vector (Dynamic) | `[42, 128]` | The types in array or vector must be the same; i.e. you cannot have `[42, true]` | | Struct | `{42, 128}` | Since structs are packed encoded, the attribute names are not encoded; i.e. `{42, 128}`; this could represent the following `struct Polygon { x: u64, y: u64 }` | | Enum | `(Active: true)` or `(1: true)` | Enums are key-val pairs with keys as being variant name (case-sensitive) or variant index (starting from 0) and values as being the variant value; this could represent the following `enum MyEnum { Inactive, Active(bool) }` | <details> <summary>Encoding cheat-sheet</summary> A few of the common types are encoded as follows: | Types | Encoding Description | Example | |--------------------------------------------|--------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------| | bool, u8 | Encoded as a single byte. `bool`: 0x00 (false) or 0x01 (true); `u8` is the byte itself. | `bool(true) = 0x01`, `u8(42) = 0x2A` | | u16 | 2-byte, big-endian | `u16(42) = 0x002A` | | u32 | 4-byte, big-endian | `u32(42) = 0x0000002A` | | u64 | 8-byte, big-endian | `u64(42) = 0x000000000000002A` | | u128 | 16-byte, big-endian | `u128(42) = 0x0000000000000000000000000000002A` | | u256, b256 | 32-byte value. For u256: big-endian integer; For b256: raw 32 bytes | `u256(42) = 32-bytes ending with ...0000002A`, `b256(...) = exactly the 32-byte array` | | Tuples, Arrays, Structs (Fixed-size) | Concatenate the encodings of each element/field with no extra padding | `(u8(1), bool(true)) = 0x01 0x01`; `[u16;2]: [42,100] = 0x002A0064`; `struct {u8,u8}: 0x0102` | | Enums | `u64` variant index + encoded variant data with no extra padding | `MySumType::X(42): 0x0000000000000000 000000000000002A` | | Bytes, String, RawSlice, Vector (Dynamic) | `u64` length prefix + raw data, no padding | `"abc" = length=3: 0x0000000000000003 0x61 0x62 0x63` | ^ This is based on the docs here: https://docs.fuel.network/docs/specs/abi/argument-encoding </details> ## Future improvements 1. Support for function signature based calls without ABI 2. Support for raw calldata input 3. Function selector completion - given ABI file ## 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. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: zees-dev <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-02-07 02:30:52 +00:00
Joshua Batty	0a56930e05	forc-debug: Add ABI support for decoding log values (#6856) ... ## Description Adds support for ABI files in `forc-debug` to decode log values while debugging using the CLI. Users can now: for example: ``` tx tx.json abi.json ``` When the Sway ABI Registry is available, the debugger will automatically fetch ABIs for deployed contracts. Have an issue open to implement this here #6862 Updates documentation to show decoded log output, adds tab completion for ABI files, and refreshes bytecode examples to match current output. The `test_cli` test has been updated to take an ABI and check that the correct decoded value is returned. ## 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-02-04 06:16:29 +01:00
Sophie Dankel	176271445c	feat: Add support for additional package manifest keys (#6868) ... ## Description Adds new keys to the package manifest's project section. These will be used when publishing packages. ## 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-01-30 09:55:10 +11:00
Cameron Carstens	b03c76e482	Introduce crypto module and expand cryptographic functions (#6837) ... ## Description This PR replaces https://github.com/FuelLabs/sway/pull/5747 and intends to introduce the crypto module. > Note: https://github.com/FuelLabs/sway/pull/6832 will also use the crypto module. The std-lib currently contains the `ecr.sw` and `vm/evm/ecr.sw` files which have the following functions: - ec_recover() - ec_recover_r1() - ed_verify() - ec_recover_address() - ec_recover_address_r1() - ec_recover_evm_address() There are a number of issues with this including no type safety for signatures from different elliptic curves, functions split across multiple files, poor naming, and generic arguments. All of these are resolved by this PR which deprecates both `ecr.sw` files and replaces them with a crypto module which syntactically matches Rust. The following new types are introduced: * `PublicKey` - An Asymmetric public key, supporting both 64 and 32-byte public keys * `Message` - Hashed message authenticated by a signature type that handles variable lengths * `Secp256k1` - A secp256k1 signature * `Secp256r1` - A secp256r1 signature * `Ed25519` - An ed25519 signature * `Signature` - An ECDSA signature All original functionality is retained with the new module: * `Secp256k1::recover()` - Recovers a public key. * `Secp256r1::recover()` - Recovers a public key. * `Secp256k1::address()` - Recovers an address. * `Secp256r1::address()` - Recovers an address. * `Secp256k1::evm_address()` - Recovers an EVM address. * `Ed25519::verify()` - Verify that a signature matches the given public key. The following new functionality has been added: * `Secp256k1::verify()` - Verify that a signature matches the given public key. * `Secp256r1::verify()` - Verify that a signature matches the given public key. * `Secp256k1::verify_address()` - Verify that a signature matches the given address. * `Secp256r1::verify_address()` - Verify that a signature matches the given address. * `Secp256k1::verify_evm_address()` - Verify that a signature matches the given EVM address. * `Secp256r1::verify_evm_address()` - Verify that a signature matches the given EVM address. * `Secp256r1::evm_address()` - Recovers an EVM address. The following functions have been deprecated: - `std::ecr::ec_recover()` - `std::ecr::ec_recover_r1()` - `std::ecr::ed_verify()` - `std::ecr::ec_recover_address()` - `std::ecr::ec_recover_address_r1()` - `std::vm::evm::ecr::ec_recover_evm_address()` Example of changes for recovering a public key: ```sway // Before fn foo(signature: B512, message: b256) { let recovered_public_key: B512 = ec_recover(signature, message).unwrap(); } // After fn bar(signature: Signature, message: Message) { let recovered_public_key: PublicKey = signature.recover(message).unwrap(); } ``` Example of changes for recovering an Address: ```sway // Before fn foo(signature: B512, message: b256) { let recovered_address: Address = ec_recover_address(signature, message).unwrap(); } // After fn bar(signature: Signature, message: Message) { let recovered_address: Address = signature.address(message).unwrap(); } ``` Complete recovery example using the `Signature` type: ```sway use std::crypto::{Message, PublicKey, Secp256r1, Signature}; fn foo() { let secp256r1_signature = Signature::Secp256r1(Secp256r1::from(( 0xbd0c9b8792876712afadbff382e1bf31c44437823ed761cc3600d0016de511ac, 0x44ac566bd156b4fc71a4a4cb2655d3da360c695edb27dc3b64d621e122fea23d, ))); let signed_message = Message::from(0x1e45523606c96c98ba970ff7cf9511fab8b25e1bcd52ced30b81df1e4a9c4323); // A recovered public key pair. let secp256r1_public_key = secp256r1_signature.recover(signed_message); assert(secp256r1_public_key.is_ok()); assert( secp256r1_public_key .unwrap() == PublicKey::from(( 0xd6ea577a54ae42411fbc78d686d4abba2150ca83540528e4b868002e346004b2, 0x62660ecce5979493fe5684526e8e00875b948e507a89a47096bc84064a175452, )), ); } ``` ## 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-01-25 23:23:40 +01:00
Daniel Frederico Lins Leite	e025355b5f	Encoding v1 docs (#6350) ... ## Description This PR introduces some slides with more detailed explanation how the "abi encoding v1" works. ## 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: K1-R1 <77465250+K1-R1@users.noreply.github.com> Co-authored-by: IGI-111 <igi-111@protonmail.com>	2025-01-24 19:14:32 +01:00
Igor Rončević	7aa59f987c	Add forc-migrate tool (#6790) ... ## Description This PR introduces `forc-migrate`, a Forc tool for migrating Sway projects to the next breaking change version of Sway. The tool addresses two points crucial for code updates caused by breaking changes: - it informs developers about the breaking changes and **assists in planing and executing** the migration. - it **automatically changes source code** where possible, reducing the manual effort needed for code changes. Besides adding the `forc-migrate` tool, the PR: - extends `Diagnostic` to support migration diagnostics aside with errors and warnings. - changes `swayfmt` to support generating source code from arbitrary lexed trees. The change is a minimal one done only in the parts of `swayfmt` that are executed by migration steps written in this PR. Adapting `swayfmt` to fully support arbitrary lexed trees will be done in #6779. The migration for the `references` feature, migrating `ref mut` to `&mut`, is developed only partially, to demonstrate the development and usage of automatic migrations that alter the original source code. The intended usage of the tool is documented in detail in the "forc migrate" chapter of The Sway Book: _Forc reference > Plugins > forc_migrate_. (The generated documentation has issues that are caused by the documentation generation bug explained in #6792. These issues will be fixed in a separate PR that will fix it for all the plugins.) We expect the `forc-migrate` to evolve based on the developer's feedback. Some of the possible extensions of the tool are: - adding additional CLI options, e.g., for executing only specific migration steps, or ignoring them. - passing parameters to migration steps from the CLI. - not allowing updates by default, if the repository contains modified or untracked files. - migrating workspaces. - migrating other artifacts, e.g., Forc.toml files or contract IDs. - migrating between arbitrary versions of Sway. - migrating SDK code. - etc. `forc-migrate` also showed a clear need for better infrastructure for writing static analyzers and transforming Sway code. The approach used in the implementation of this PR should be seen as a pragmatic beginning, based on the reuse of what we currently have. Some future options are discussed in #6836. ## Demo ### `forc migrate show` Shows the breaking change features and related migration steps. This command can be run anywhere and does not require a Sway project. ``` Breaking change features: - storage_domains (https://github.com/FuelLabs/sway/issues/6701) - references (https://github.com/FuelLabs/sway/issues/5063) Migration steps (1 manual and 1 semiautomatic): storage_domains [M] Review explicitly defined slot keys in storage declarations (`in` keywords) references [S] Replace `ref mut` function parameters with `&mut` Experimental feature flags: - for Forc.toml: experimental = { storage_domains = true, references = true } - for CLI: --experimental storage_domains,references ``` ### `forc migrate check` Performs a dry-run of the migration on a concrete Sway project. It outputs all the occurrences in code that need to be reviewed or changed, as well as the migration time effort: ``` info: [storage_domains] Review explicitly defined slot keys in storage declarations (`in` keywords) --> /home/kebradalaonda/Desktop/M Forc migrate tool/src/main.sw:19:10 | ... 19 | y in b256::zero(): u64 = 0, | ------------ 20 | z: u64 = 0, 21 | a in calculate_slot_address(): u64 = 0, | ------------------------ 22 | b in 0x0102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f20: u64 = 0, | ------------------------------------------------------------------ | = help: If the slot keys used in `in` keywords represent keys generated for `storage` fields = help: by the Sway compiler, those keys might need to be recalculated. = help: = help: The previous formula for calculating storage field keys was: `sha256("storage.<field name>")`. = help: The new formula is: `sha256((0u8, "storage.<field name>"))`. = help: = help: For a detailed migration guide see: https://github.com/FuelLabs/sway/issues/6701 ____ Migration effort: storage_domains [M] Review explicitly defined slot keys in storage declarations (`in` keywords) Occurrences: 3 Migration effort (hh::mm): ~00:06 references [S] Replace `ref mut` function parameters with `&mut` Occurrences: 0 Migration effort (hh::mm): ~00:00 Total migration effort (hh::mm): ~00:06 ``` ### `forc migrate run` Runs the migration steps and guides developers through the migration process. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-01-20 13:14:20 +01:00
Igor Rončević	4fe687094e	Implement Iterator for StorageVec (#6821) ... ## Description This PR implements `Iterator` for `StorageVec`. Iterating over a `StorageVec` via `for` loop should now be the preferred option. Compared to the traversal via `while` loop and incrementing index, the `for` loop is: - more performant. `for` loop eliminates the redundant boundary checks done in every `get()` call in the `while` loop. - more idiomatic and convenient. Closes #6796. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: bitzoic <bitzoic.eth@gmail.com>	2025-01-14 16:18:16 +01:00
Marcos Henrich	e40ebf4157	Implements fully working hierarchical lexical scopes. (#6784) ... ## Description This PR implements the missing elements for the hierarchical lexical scopes. TypeCheckContext no longer uses cloned namespaces. Instead, we push and pop lexical scopes. For this to work multiple places that used current_items now either use root_items or traverse the lexical scopes. ## 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. - [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: João Matos <joao@tritao.eu> Co-authored-by: IGI-111 <igi-111@protonmail.com>	2025-01-13 11:02:20 +11:00
Yash Jagtap	8fe2bd6ed2	fix: typos cleanup (#6799) ... ## Description fixed 3 typos ## Checklist - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2025-01-06 11:38:00 +11:00
Matt	cf7b6664b5	docs: add sway memory model (#6775) ... ## Description Developers get confused by Sway's memory model as it is different from Rust's. So I added this to the docs. closes https://app.asana.com/0/1207924201336629/1208429018056446 ## Checklist - [x] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - x ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>	2024-12-20 10:47:39 -06:00
zees-dev	519f208a05	Forc.toml metadata support (#6728) ... # Description Adds support for `metadata` as `[project.metadata]` or `[workspace.metadata]` in `Forc.toml` of value `toml::Value` - Addresses: 22bf3936a3/text/rfcs/0006-metadata-in-forc-manifest.md (reference-level-explanation) - Resolves: https://github.com/FuelLabs/sway/issues/2180 ## Linked examples of usage - https://github.com/FuelLabs/example-forc-plugins/pull/1 --------- Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>	2024-11-19 16:48:32 +13:00
Kaya Gökalp	8073fab0b6	docs: remove dead links to sway-libs/fixed-point (#6689) ... ## Description closes #6636. closes #6631. As of https://github.com/FuelLabs/sway-libs/pull/278 sway-libs/fixed-point library is deprecated and removed completely from sway-libs repo. We should not link it from our book as well.	2024-11-03 23:39:54 -08:00
0x77	7e499fe24d	[docs] Update ::call_frames::ContractId to ::contract_id::ContractId in Native Assets Documentation (#6141) ... ## Description The syntax `std::call_frames::ContractId` has been updated in the latest version of Sway. The new syntax is `std::contract_id::ContractId`. To ensure the documentation is accurate and consistent with the latest version, this update is necessary. ## Reason for Change: - The `std::call_frames::ContractId` syntax has been deprecated or modified in the latest version of Sway. - Using the latest `std::contract_id::ContractId` syntax ensures the documentation is accurate and helps developers avoid using outdated syntax. ## Reference #5867 ## 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). - [ ] I have requested a review from the relevant team or maintainers. Co-authored-by: IGI-111 <igi-111@protonmail.com>	2024-10-28 14:48:26 +01:00
mcisb	cbfd9621d0	style: update troubleshooting.md (#6632) ... Co-authored-by: K1-R1 <77465250+K1-R1@users.noreply.github.com> Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2024-10-16 10:02:56 +11:00
Sophie Dankel	98d821b6ed	add new target to forc (#6621) ... ## 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: Alfie John <alfie@alfie.wtf> Co-authored-by: Joshua Batty <joshpbatty@gmail.com>	2024-10-14 21:00:25 -07:00
Kaya Gökalp	b465e19284	fix: pin forc-deploy to use 100kb blob size by default (#6616) ... ## Description Pins forc-deploy chunk sizes to 100kb to fix errors while deploying chunked contracts. To unblock an ecosystem project, the PR is marked critical.	2024-10-07 05:10:36 -07:00
Kaya Gökalp	347c83473a	feat: add blob deployments for scripts and predicates (#6607) ... ## Description This PR adds support for deploying executables, namely predicates and scripts. Before this PR executing `forc-deploy` on a script or predicate was an hard error. With this PR we are enabling the deployment of them via converting them to a loader which loads the original bytecode deployed as a blob. The loader binaries are serialized to disk under `out` folder for both predicates and scripts. For predicates we also save the root of the loader additionally. Every output related to generated `loader` is suffixed with `-loader` so that it can be distinguished easily. --------- Co-authored-by: Joshua Batty <joshpbatty@gmail.com> Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>	2024-10-06 17:12:36 +11:00
Cameron Carstens	f14af85025	Update single and multi asset example in docs hub (#6594) ... ## Description The single and multi asset examples in the docs hub do not use the latest versions of the SRC3 and SRC20 standard. This has been updated to follow the specifications. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2024-09-29 10:16:31 +02:00
Samuel Moelius	c55ad21e3e	Fix "Testing with Rust / Writing Tests" example (#5539) ... ## Description The harnes.rs code that currently appears in the book seems to be out of date (it doesn't compile). The proposed code was copied from the [`sway-test-rs` template](1fee545237/templates/sway-test-rs/template/tests/harness.rs (L1-L36)). (The Sway tutorial is very good, BTW.) ## Checklist - [ ] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: IGI-111 <igi-111@protonmail.com> Co-authored-by: Sophie Dankel <47993817+sdankel@users.noreply.github.com>	2024-09-10 09:48:27 +10:00