🌴 Empowering everyone to build reliable and efficient smart contracts.
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
Create devcontainer.json (#4377) ## Description This PR adds a configuration for github codespaces, so that anyone can create a codespace from this repo with forc, cargo, and the Rust & Sway VSCode plugins installed. ## 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. | 3 年前 | |
Removing verify-ir from the CLI (#7672) ## Description This PR removes "verify-ir" from the CLI, because we now run verify after each optimization pass. The performance impact seems to be minimal and it is well worthy the extra security it brings. This brought to attention a problem that the pass "arg-demotion" had with blocks with "never" as arguments. A better fix will be pushed later, but for now, the pass does not generate a miscompilation anymore. Otehr smal fixes were "filter-fn" not working with contracts, and the IR printer not correctly printings storage key address with 64 characters when they start with zero. ## 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. | 1 个月前 | |
Fix `function_cache` garbage collection bug (#6555) ## Description Fixes a bug that would crash the language server when a function node was part of the AST. #5967 added a function cache to the `QueryEngine`. Garbage collection needed to be called on this otherwise it returns references to types that have been cleared from the other engines during garbage collection. In the future, any other nodes that we decide to cache need to have GC applied to them or we will end up crashing the language server on the first key-pressed event. I've also removed the gc_frequency setting and now run GC on each keystroke. Without doing this, the spans stored in the TokenMap and what was returned from the compiler were falling out of sync. This ensures that everything is always up to date and the correct spans are used. closes #5260 Finally, I've added a `launch.json` that allows for attaching `lldb` to a live running `forc-lsp` process. This was a pretty cruical step for tracking down this bug so would be nice to have it easily accessible for future debugging sessions. ## 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: Sophie Dankel <47993817+sdankel@users.noreply.github.com> | 1 年前 | |
Update Rust in dockerfile to 1.87 (#7201) | 1 年前 | |
Implement `__mem_rep_eq` intrinsic (#7697) ## Description This PR introduces a new `__mem_repr_eq` intrinsic for comparing memory representation of types, and removes the existing `__runtime_mem_id` and `__encoding_mem_id` intrinsics. We decided to introduce `__mem_repr_eq` to mitigate the following issues we had with existing intrinsics: - `mem_id`s were `u64` values computed using `DefaultHasher` whose results are not guaranteed to be stable across different runs of the same Sway compiler or being same on different target architectures. - even if we switched to a stable hasher, hashing to `u64` was not giving a strong no-collision guarantee. A hash collision between different, e.g. runtime and encoding representation, would in case of false positives result in wrong encoding or decoding. The `__mem_repr_eq` is defined as: ```sway __mem_repr_eq<T>(repr_a: str, repr_b: str) -> bool ``` It returns `true` if the memory representation `repr_a` of the type `T` is equal to its memory representation `repr_b`, assuming `T` has both memory representations. If `T` does not have any of the representations `repr_a` or `repr_b`, returns `false`. The valid values for `repr_a` and `repr_b` are `"runtime"`, `"encoding"`, and `"hashing"`: - `"runtime"` is how the type is represented inside the VM's memory. This is the Sway runtime memory representation (e.g., struct fields are aligned to word boundaries, arrays are packed, etc.). This memory representation is defined for every type. - `"encoding"` is the packed memory representation of a type, as defined by the canonical ABI encoding. Not all types have a canonical ABI encoding defined, e.g., dynamic types like `Vec` or `raw_slice`. In that case, `"encoding"` never compares equal to any other memory representation, __including to itself__. - `"hashing"` is the packed memory representation of a type, as defined by the canonical hashing introduced in #7695. Not all types have a canonical hashing defined, e.g., dynamic types like `Vec` or `raw_slice`. In that case, `"hashing"` never compares equal to any other memory representation, __including to itself__. To test if a type `T` has `"encoding"` or `"hashing"` memory representation defined, compare that representation to itself. E.g.: `let has_encoding_repr = __mem_repr_eq<T>("encoding", "encoding");` `repr_a` and `repr_b` must be compile-time constant `str`s, whose values are one of `"runtime"`, `"encoding"`, or `"hashing"`. The constant `str`s never end up in the bytecode. Additionally, the PR moves existing E2E intrinsics tests that were not in the `language/intrinsics` into `language/intrinsics`. ## Breaking Change The old `__runtime_mem_id` and `__encoding_mem_id` intrinsics are removed. The code that is using them must switch to the new `__mem_repr_eq`. ## 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. | 1 个月前 | |
Optimize hashing by implementing `is_hash_trivial` (#7695) ## Description This PR extends the `Hash` trait with the `is_hash_trivial() -> bool` associated function. This function is supposed to return true if the hash byte representation of the type is the same as its runtime memory representation. By using `is_hash_trivial`, `std::hash::sha256` and `keccak256` module functions can skip expensive `Bytes` creation in the `Hasher` and directly hash the value's memory content. This optimization is similar to what `is_encode/decode_trivial()` associated functions are providing for ABI encoding/decoding. Similar to ABI encoding/decoding, implementation of hashing for a type is in full control of the Sway package that owns the type. In practice, and in `std` in particular, non-dynamic types are in general trivially hashable if their packed memory representation is the same as their runtime memory representation. Because of this, when implementing `Hash` for tuples, we use the `__runtime_mem_id` and the `__encoding_mem_id` intrinsics. While using the `__encoding_mem_id` might look like coupling encoding and hashing, it is not. What we are actually using is the notion of the "packed memory representation" that the `__encoding_mem_id` provides. Unfortunately, the intrinsic that provides this information was originally created for ABI encoding and not for a more generic usage, e.g., `__packed__mem_id`. To make the distinction clear and remove what looks like coupling of unrelated concepts, we will provide a follow-up PR that introduces intrinsics for use case based memory layouts: - `__mem_repr_id_runtime` - `__mem_repr_id_encoding` - `__mem_repr_id_hashing` Currently, all enums in the `std` hash their descriminators as `u8`. This makes them all being non-trivially hashable. For many of them, hashing the descriminator as `u64` would make them trivially hashable. This is however a breaking change that potentially affects the hashed data we already have deployed, e.g., `StorageMap` keys. In the future, we can provide this breaking change behind a feature flag. Enums that can benefit from being trivially hashed are marked in code with `TODO: (HASH-TRIVIAL-ENUMS)`. ## 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. - [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. | 1 个月前 | |
Optionally print IR metadata block (#7684) ## Description This PR makes printing of the IR metadata block optional. For IR analysis, in most of the cases, the printed IR just introduces clutter. It is now not printed by default. To print it, `print-md` directive must be added to the `--ir` CLI argument (or `--print-ir` in E2E tests). E.g.: ``` --ir all modified print-md --if final print-md ``` IR metadata is removed from almost all the snapshots, except the two that use the whole `sway-lib-std`. Seeing changes in metadata when changing `std` code is still useful. The `filter-fn` option in snapshot tests was previously relying on the first `!0` as an end of the printed IR step. This is now changed to checking for a `}` in at the beginning of a line. ## Breaking Change Strictly seen, this is a breaking change, in case someone prints IR and relies on having metadata printed. ## 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. | 1 个月前 | |
Implement dynamic storage opcodes in the compiler (#7595) ## Description This PR is a step in implementing #7560. It adds compiler support for [dynamic storage opcodes](https://github.com/FuelLabs/fuel-specs/pull/640) by: - supporting all opcodes in `asm` blocks. - adding IR instructions for all opcodes. Note that the `FuelVmInstruction::StatePreload` IR instruction returns zero if the slot is not used, but also if it is used and contains zero-sized content. The reason is that zero-sized storage types, like, e.g. `StorageVec`, have special semantics in the storage API and the `storage_api` does not write zero-sized types into storage, nor reads them. Modeling the IR instruction this way preserves this semantics and allows for more efficient implementation that is actually needed in the API. (Returning both the length and the existence information would require a stack allocation and more gas expensive compilation for something that is actually not used.) This API semantics might be changed to support zero-sized types like any other types. This would be a separate breaking change and a part of [Configurable and composable storage RFC](https://github.com/FuelLabs/sway-rfcs/pull/40). Meanwhile, if a distinction between unused and zero-sized used slot is needed while preloading, it can be achieved by using the `SPLD` opcode in `asm` block. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. | 4 个月前 | |
Removing verify-ir from the CLI (#7672) ## Description This PR removes "verify-ir" from the CLI, because we now run verify after each optimization pass. The performance impact seems to be minimal and it is well worthy the extra security it brings. This brought to attention a problem that the pass "arg-demotion" had with blocks with "never" as arguments. A better fix will be pushed later, but for now, the pass does not generate a miscompilation anymore. Otehr smal fixes were "filter-fn" not working with contracts, and the IR printer not correctly printings storage key address with 64 characters when they start with zero. ## 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. | 1 个月前 | |
feat: forc-call abi backtracing (#7502) ## Description This PR introduces panic/error traces to the forc call trace output. This functionality is built on top of the existing abi-backtracing introduced in the following: - https://github.com/FuelLabs/sway-rfcs/blob/master/rfcs/0016-abi-backtracing.md - https://github.com/FuelLabs/sway/pull/7224 - https://github.com/FuelLabs/sway/pull/7277 - https://github.com/FuelLabs/fuel-abi-types/pull/36 - https://github.com/FuelLabs/fuel-abi-types/pull/40/files Supplying verbosity level greater than 1 (i.e. `-vv` or `-v=2`) will display the panic/error traces when using `forc-call`. If the called function panics, the panic message and the full backtrace will be displayed in the trace output. ## Example <details> <summary>Example contract code</summary> ```sway contract; abi AbiErrorDemo { #[storage(write)] fn write_non_zero(value: u64); #[storage(read)] fn read_value() -> u64; } storage { value: u64 = 0, } #[error_type] pub enum PanicError { #[error(m = "The provided value must be greater than zero.")] ZeroValue: (), } impl AbiErrorDemo for Contract { #[storage(write)] fn write_non_zero(value: u64) { set_non_zero_value(value); } #[storage(read)] fn read_value() -> u64 { storage.value.read() } } #[trace(always)] #[storage(write)] fn set_non_zero_value(value: u64) { ensure_non_zero(value); storage.value.write(value); } #[trace(always)] fn ensure_non_zero(value: u64) { ensure_non_zero_impl(value); } #[trace(always)] fn ensure_non_zero_impl(value: u64) { if value == 0 { panic PanicError::ZeroValue; } } ``` </details> Example Call: ```sh cargo run -p forc-client --bin forc-call -- \ --abi out/debug/abi_errors-abi.json \ babdc125da45eac42309e60d3aea63a53843f5ff2438d1a88bf8c788e8348c58 \ write_non_zero "0" -vv ``` Example Output: <img width="857" height="340" alt="Screenshot 2025-11-24 at 8 36 00 PM" src="https://github.com/user-attachments/assets/9a14053e-9318-4543-a01a-0d794e30dff2" /> ## 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. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > Adds ABI-aware revert decoding to forc-call, displaying panic messages, values, and backtraces in verbose traces and surfacing revert errors early. > > - **forc-client (call/trace)**: > - Add ABI-aware revert decoding (`RevertInfoSummary`) and integrate into `TraceEvent::Revert`; render panic message, value, location, and backtrace in `display_transaction_trace`. > - New helpers: `decode_revert_info` and `first_revert_info` to extract revert details from receipts and trace. > - `call_function`: generate receipts once, include in interpreter, display detailed info on verbosity, and return an error early when a revert is detected; parse outputs after. > - Minor: reference `trace::display_transaction_trace` directly; extend tests to cover revert detail rendering. > - **forc-util**: > - Add `revert_info_from_receipts` to build `RevertInfo` (revert code, panic metadata) from receipts using optional ABI. > - **forc-test**: > - Replace `revert_code()` with `revert_info()` using new utility; filter by actual revert code; simplify API. > - **Docs**: > - Add "Seeing revert information and backtraces" section with example usage/output for `forc call -vv`. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 957d411acb36ddc38f5daf3e22f488f31a5bd22e. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY --> --------- Co-authored-by: z <zees-dev@users.noreply.github.com> | 9 个月前 | |
Optionally print IR metadata block (#7684) ## Description This PR makes printing of the IR metadata block optional. For IR analysis, in most of the cases, the printed IR just introduces clutter. It is now not printed by default. To print it, `print-md` directive must be added to the `--ir` CLI argument (or `--print-ir` in E2E tests). E.g.: ``` --ir all modified print-md --if final print-md ``` IR metadata is removed from almost all the snapshots, except the two that use the whole `sway-lib-std`. Seeing changes in metadata when changing `std` code is still useful. The `filter-fn` option in snapshot tests was previously relying on the first `!0` as an end of the printed IR step. This is now changed to checking for a `}` in at the beginning of a line. ## Breaking Change Strictly seen, this is a breaking change, in case someone prints IR and relies on having metadata printed. ## 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. | 1 个月前 | |
Refactor `DeclEngine` for robustness and semantic consistency (#7704) ## Description This PR is a prerequisite for an upcoming performance optimization of the `DeclEngine`, aimed at additional removals of copied `TyDecl` entries from the `DeclEngine`. The PR: - properly implements `HasChanges` for `MaterializeConstGenerics::materialize_const_generics`. During compilation of the o2 `order-book` contract, this change removes 104 duplicated function decls and 894 duplicated struct decls. - removes `insert_arc` from the `DeclEngine`. The semantic of this method made no sense for its existing usages. In all usages, we were inserting an existing declaration gotten from the `DeclEngine` and just giving it a different `DeclId`. In other words, calling `DeclEngine::get_...` would for both `DeclId`s return exactly the same declaration. Additionally, all those usages were only in ABI declarations, for ABI's `TyImplItem::Fn/Constant/Type` where none of those can be modified afterwards in any way (e.g., we do not support them being generic in ABIs). As expected, removing `insert_arc` and replacing its returned `DeclRef` with the original didn't change semantic of any calls that were using it. - adds `insert_modified` method to the `DeclEngine` and forces `insert` to provide `ParsedDeclId`. Previous approach in which callers were responsible for either passing the `ParsedDeclId` for the first time or getting it by `get_parsed_decl_id` was both verbose and error-prone. There were cases in code, some even marked with TODO, where the `ParsedDeclId` was not provided when inserting a modified declaration, essentially inserting declarations that were not connected to their parsed equivalents. - adds `insert_dummy_func` method to the `DeclEngine` to clearly distinguish the only case in which a typed declaration does not have the corresponding parsed declaration. - fixes the bug of having two different fields for parsed const generics in the `DeclEngine`: `const_generic_parsed_decl_id_map` and `const_generic**s**_parsed_decl_id_map`. The plural version was used for writing and singular for reading, effectively resulting in const generics never having their corresponding parsed declarations attached. - wires all instances of `ConstGenericParameter` with their corresponding `ParsedDeclId`s. Previously this was done for const generics in functions and impls, but not in structs, enums, and traits. Additionally, the PR: - adds `run-tests.sh` and `just t` recipe for convenient running of the base set of Sway compiler tests. ## Checklist - [ ] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. | 23 天前 | |
Implement `__mem_rep_eq` intrinsic (#7697) ## Description This PR introduces a new `__mem_repr_eq` intrinsic for comparing memory representation of types, and removes the existing `__runtime_mem_id` and `__encoding_mem_id` intrinsics. We decided to introduce `__mem_repr_eq` to mitigate the following issues we had with existing intrinsics: - `mem_id`s were `u64` values computed using `DefaultHasher` whose results are not guaranteed to be stable across different runs of the same Sway compiler or being same on different target architectures. - even if we switched to a stable hasher, hashing to `u64` was not giving a strong no-collision guarantee. A hash collision between different, e.g. runtime and encoding representation, would in case of false positives result in wrong encoding or decoding. The `__mem_repr_eq` is defined as: ```sway __mem_repr_eq<T>(repr_a: str, repr_b: str) -> bool ``` It returns `true` if the memory representation `repr_a` of the type `T` is equal to its memory representation `repr_b`, assuming `T` has both memory representations. If `T` does not have any of the representations `repr_a` or `repr_b`, returns `false`. The valid values for `repr_a` and `repr_b` are `"runtime"`, `"encoding"`, and `"hashing"`: - `"runtime"` is how the type is represented inside the VM's memory. This is the Sway runtime memory representation (e.g., struct fields are aligned to word boundaries, arrays are packed, etc.). This memory representation is defined for every type. - `"encoding"` is the packed memory representation of a type, as defined by the canonical ABI encoding. Not all types have a canonical ABI encoding defined, e.g., dynamic types like `Vec` or `raw_slice`. In that case, `"encoding"` never compares equal to any other memory representation, __including to itself__. - `"hashing"` is the packed memory representation of a type, as defined by the canonical hashing introduced in #7695. Not all types have a canonical hashing defined, e.g., dynamic types like `Vec` or `raw_slice`. In that case, `"hashing"` never compares equal to any other memory representation, __including to itself__. To test if a type `T` has `"encoding"` or `"hashing"` memory representation defined, compare that representation to itself. E.g.: `let has_encoding_repr = __mem_repr_eq<T>("encoding", "encoding");` `repr_a` and `repr_b` must be compile-time constant `str`s, whose values are one of `"runtime"`, `"encoding"`, or `"hashing"`. The constant `str`s never end up in the bytecode. Additionally, the PR moves existing E2E intrinsics tests that were not in the `language/intrinsics` into `language/intrinsics`. ## Breaking Change The old `__runtime_mem_id` and `__encoding_mem_id` intrinsics are removed. The code that is using them must switch to the new `__mem_repr_eq`. ## 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. | 1 个月前 | |
Refactor `DeclEngine` for robustness and semantic consistency (#7704) ## Description This PR is a prerequisite for an upcoming performance optimization of the `DeclEngine`, aimed at additional removals of copied `TyDecl` entries from the `DeclEngine`. The PR: - properly implements `HasChanges` for `MaterializeConstGenerics::materialize_const_generics`. During compilation of the o2 `order-book` contract, this change removes 104 duplicated function decls and 894 duplicated struct decls. - removes `insert_arc` from the `DeclEngine`. The semantic of this method made no sense for its existing usages. In all usages, we were inserting an existing declaration gotten from the `DeclEngine` and just giving it a different `DeclId`. In other words, calling `DeclEngine::get_...` would for both `DeclId`s return exactly the same declaration. Additionally, all those usages were only in ABI declarations, for ABI's `TyImplItem::Fn/Constant/Type` where none of those can be modified afterwards in any way (e.g., we do not support them being generic in ABIs). As expected, removing `insert_arc` and replacing its returned `DeclRef` with the original didn't change semantic of any calls that were using it. - adds `insert_modified` method to the `DeclEngine` and forces `insert` to provide `ParsedDeclId`. Previous approach in which callers were responsible for either passing the `ParsedDeclId` for the first time or getting it by `get_parsed_decl_id` was both verbose and error-prone. There were cases in code, some even marked with TODO, where the `ParsedDeclId` was not provided when inserting a modified declaration, essentially inserting declarations that were not connected to their parsed equivalents. - adds `insert_dummy_func` method to the `DeclEngine` to clearly distinguish the only case in which a typed declaration does not have the corresponding parsed declaration. - fixes the bug of having two different fields for parsed const generics in the `DeclEngine`: `const_generic_parsed_decl_id_map` and `const_generic**s**_parsed_decl_id_map`. The plural version was used for writing and singular for reading, effectively resulting in const generics never having their corresponding parsed declarations attached. - wires all instances of `ConstGenericParameter` with their corresponding `ParsedDeclId`s. Previously this was done for const generics in functions and impls, but not in structs, enums, and traits. Additionally, the PR: - adds `run-tests.sh` and `just t` recipe for convenient running of the base set of Sway compiler tests. ## Checklist - [ ] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. | 23 天前 | |
Implement `__mem_rep_eq` intrinsic (#7697) ## Description This PR introduces a new `__mem_repr_eq` intrinsic for comparing memory representation of types, and removes the existing `__runtime_mem_id` and `__encoding_mem_id` intrinsics. We decided to introduce `__mem_repr_eq` to mitigate the following issues we had with existing intrinsics: - `mem_id`s were `u64` values computed using `DefaultHasher` whose results are not guaranteed to be stable across different runs of the same Sway compiler or being same on different target architectures. - even if we switched to a stable hasher, hashing to `u64` was not giving a strong no-collision guarantee. A hash collision between different, e.g. runtime and encoding representation, would in case of false positives result in wrong encoding or decoding. The `__mem_repr_eq` is defined as: ```sway __mem_repr_eq<T>(repr_a: str, repr_b: str) -> bool ``` It returns `true` if the memory representation `repr_a` of the type `T` is equal to its memory representation `repr_b`, assuming `T` has both memory representations. If `T` does not have any of the representations `repr_a` or `repr_b`, returns `false`. The valid values for `repr_a` and `repr_b` are `"runtime"`, `"encoding"`, and `"hashing"`: - `"runtime"` is how the type is represented inside the VM's memory. This is the Sway runtime memory representation (e.g., struct fields are aligned to word boundaries, arrays are packed, etc.). This memory representation is defined for every type. - `"encoding"` is the packed memory representation of a type, as defined by the canonical ABI encoding. Not all types have a canonical ABI encoding defined, e.g., dynamic types like `Vec` or `raw_slice`. In that case, `"encoding"` never compares equal to any other memory representation, __including to itself__. - `"hashing"` is the packed memory representation of a type, as defined by the canonical hashing introduced in #7695. Not all types have a canonical hashing defined, e.g., dynamic types like `Vec` or `raw_slice`. In that case, `"hashing"` never compares equal to any other memory representation, __including to itself__. To test if a type `T` has `"encoding"` or `"hashing"` memory representation defined, compare that representation to itself. E.g.: `let has_encoding_repr = __mem_repr_eq<T>("encoding", "encoding");` `repr_a` and `repr_b` must be compile-time constant `str`s, whose values are one of `"runtime"`, `"encoding"`, or `"hashing"`. The constant `str`s never end up in the bytecode. Additionally, the PR moves existing E2E intrinsics tests that were not in the `language/intrinsics` into `language/intrinsics`. ## Breaking Change The old `__runtime_mem_id` and `__encoding_mem_id` intrinsics are removed. The code that is using them must switch to the new `__mem_repr_eq`. ## 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. | 1 个月前 | |
Promote `const_generics` to a standard feature (#7592) ## Description This PR promotes `const_generics` to a standard feature not anymore behind a feature flag. #7512 made `const_generic` experimental feature enabled by default, but still kept it as experimental, with the decision to remove the feature flag as a part of the next breaking release 0.71.0. - Closes #6860. ## Breaking change The `const_generic` experimental feature is removed. If a compilation used `--experimental/no-experimental const_generic` or `#[cfg(experimental_const_generics)]` it will fail now. The solution is to simply remove all the usages of the feature flag. ## 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) - [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. | 4 个月前 | |
Add missing IR passes to `PassManager::OPTIMIZATION_PASSES` (#7698) | 1 个月前 | |
Bump to 0.72.0 (#7699) ## Description This PR bumps the repo version to a breaking change v0.72.0. ## 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. | 1 个月前 | |
fix modified in optimisation passes so they converge (#7666) ## Description This PR fix the `modified` return of some optimisation passes, so we can run optimisations multiple times until they converge. To guarantee that they are correct, we now have an "env var" named "SWAY_VERIFY_FORCE" that forces IR verification and checks whether the modified flag is the same as the comparison of the IR before and after the pass. The flag is being set for all snapshot tests. As discussed, it makes sense to remove the "verify" CLI flag. For this last check, I had to write the "mut" of function and block arguments in the IR; otherwise, the "mutability-tagger" pass would return true, but without any visible change in the IR, the check would always fail. This triggered a LOT of changes, given that we assume everything is mutable by default. On the bright side is that it is now much easier to see improvements to the tagger pass. There are also other small improvements in the form of "TODO", because if Sway can guarantee that a value is never written, we can generate the initial IR already flagging something as immutable. Another big change was the removal of "file-checks" for some IR tests. We already have snapshot tests for them, and given that the snapshot shows the complete diff, it is much easier to see the exact difference of each pass. I left normal comments though. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. | 2 个月前 | |
fix modified in optimisation passes so they converge (#7666) ## Description This PR fix the `modified` return of some optimisation passes, so we can run optimisations multiple times until they converge. To guarantee that they are correct, we now have an "env var" named "SWAY_VERIFY_FORCE" that forces IR verification and checks whether the modified flag is the same as the comparison of the IR before and after the pass. The flag is being set for all snapshot tests. As discussed, it makes sense to remove the "verify" CLI flag. For this last check, I had to write the "mut" of function and block arguments in the IR; otherwise, the "mutability-tagger" pass would return true, but without any visible change in the IR, the check would always fail. This triggered a LOT of changes, given that we assume everything is mutable by default. On the bright side is that it is now much easier to see improvements to the tagger pass. There are also other small improvements in the form of "TODO", because if Sway can guarantee that a value is never written, we can generate the initial IR already flagging something as immutable. Another big change was the removal of "file-checks" for some IR tests. We already have snapshot tests for them, and given that the snapshot shows the complete diff, it is much easier to see the exact difference of each pass. I left normal comments though. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. | 2 个月前 | |
Removing verify-ir from the CLI (#7672) ## Description This PR removes "verify-ir" from the CLI, because we now run verify after each optimization pass. The performance impact seems to be minimal and it is well worthy the extra security it brings. This brought to attention a problem that the pass "arg-demotion" had with blocks with "never" as arguments. A better fix will be pushed later, but for now, the pass does not generate a miscompilation anymore. Otehr smal fixes were "filter-fn" not working with contracts, and the IR printer not correctly printings storage key address with 64 characters when they start with zero. ## 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. | 1 个月前 | |
Extend compiler metrics with `DeclEngine` metrics (#7664) ## Description This PR adds basic `DeclEngine` metrics to compiler metrics, available via `--metrics-outfile` `forc` CLI option. The metrics give information about slab occupancy and approximate memory usage. ## Checklist - [ ] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. | 2 个月前 | |
Fix forc-fmt empty if-body + else collapsing onto one line (#7628) ## Description Fixes #7625 `forc-fmt` collapses empty if-body + else onto a single line: ```sway // Before (wrong): if __size_of::<T>() == 0 { } else if __is_reference_type::<T>() { // After (correct): if __size_of::<T>() == 0 { } else if __is_reference_type::<T>() { ``` **Root cause**: In `format_then_block`, when the then-block is empty and has an else clause, `block_unindent()` was called but no newline was written — so the closing `}` from `format_else_opt` ended up on the same line. **Fix**: Write a newline after the empty body when an else clause exists, and skip `block_unindent` since `close_curly_brace` in `format_else_opt` already handles unindentation. Guarded with `LineStyle::Inline` to avoid injecting newlines during width measurement probes. ## Checklist - [x] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [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: Igor Rončević <ironcev@hotmail.com> | 1 个月前 | |
Verify all jumps on asm are using ControlFlowOp (#7563) ## Description This PR will be useful for https://github.com/FuelLabs/sway/pull/7550 testing. Currently, we expect all jumps to use `ControlFlowOp`. We have two exceptions at the moment: 1 - JAL when returning from functions; 2 - and `__jmp_mem()` used on `run_external`. This PR fixes both by removing all jumps from the `VirtualOp` enum. There is also another problem with `VirtualOp::successor`. Currently, `JAL` is reporting the next instruction as its successor, which is not true. ## New `patch-bin` and `fuel-vm` snapshot command One issue raised below was that removing jumps from the enum makes it harder to test/debug some applications. To solve that we now have one new snapshot test command: `patch-bin`. As the name implies it pacthes the binary and allow us to inject any instruction, even invalid ones, directly into `asm` blocks. Example: ```rust fn main() -> u64 { asm(r1, r0: 0) { addi r1 r0 i3; log r0 r0 r0 r0; // PATCH: 0x50 010000 010000 000000 000100 addi r1 r1 i5; r1: u64 } } ``` The command will search for the comment above, then it will search inside the `DWARF` file the instruction that is marked to this same line; then it will parse the command in the comments and patch the binary directly. After that we can run the patched binary directly with another new command: `fuel-vm`. Example: ```toml cmds = [ "forc build --path {root}", "patch-bin debug", "fuel-vm run {root}/out/debug/asm_patch.bin" ] ``` These commands need improvements. So let us consider them as POCs at this stage. I vote for leaving this test there, and it can even be the sandbox for tests directly. ## Removing templates tests from CI This PR is also removing templates tests from CI because we will move these tests to the Rust SDK repo, where makes more sense for them to be. In a future PR I will remove these templates from this repo and update the docs. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. | 5 个月前 | |
Bump quinn-proto from 0.11.14 to 0.11.16 in /test/src/sdk-harness (#7700) Bumps [quinn-proto](https://github.com/quinn-rs/quinn) from 0.11.14 to 0.11.16. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/quinn-rs/quinn/releases">quinn-proto's releases</a>.</em></p> <blockquote> <h2>quinn-proto-0.11.16</h2> <h2>What's Changed</h2> <ul> <li>0.11.x: upgrade dependencies by <a href="https://github.com/djc"><code>@djc</code></a> in <a href="https://redirect.github.com/quinn-rs/quinn/pull/2707">quinn-rs/quinn#2707</a></li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/quinn-rs/quinn/commit/a96949f6cd257c665f544626af4e8ce668a40b30"><code>a96949f</code></a> Take semver-compatible update for anyhow</li> <li><a href="https://github.com/quinn-rs/quinn/commit/5429f60d0ee9971770e60f0407d992d3b912d274"><code>5429f60</code></a> udp: bump version to 0.5.15</li> <li><a href="https://github.com/quinn-rs/quinn/commit/262a493629acdc979070cd36d801464a2b8dd3e2"><code>262a493</code></a> proto: bump version to 0.11.16</li> <li><a href="https://github.com/quinn-rs/quinn/commit/c19b63a04c6eff60684a845fce29fee6d74b1acd"><code>c19b63a</code></a> Upgrade rustls-platform-verifier to 0.7</li> <li><a href="https://github.com/quinn-rs/quinn/commit/aff3652c43be3491908ef553fac16610c9ad3e6a"><code>aff3652</code></a> Disable default features for fastbloom</li> <li><a href="https://github.com/quinn-rs/quinn/commit/01b2eee2c68b1d73ad09485b440fbfa8f6d3e290"><code>01b2eee</code></a> Upgrade fastbloom to 0.17</li> <li><a href="https://github.com/quinn-rs/quinn/commit/2c82013a8cd502f3dd0bba0a4c38a51e564d29cc"><code>2c82013</code></a> Switch BBR RNG to PCG</li> <li><a href="https://github.com/quinn-rs/quinn/commit/544dd9ebabf18639cb2041f849ea406100dd3d6d"><code>544dd9e</code></a> Upgrade to rand 0.10.1</li> <li><a href="https://github.com/quinn-rs/quinn/commit/a7499b8439e393a6299330111d9c8564cd96c464"><code>a7499b8</code></a> Bump versions for release</li> <li><a href="https://github.com/quinn-rs/quinn/commit/7c1970f19b24280af86b1a0a1c2d06d59fc453f0"><code>7c1970f</code></a> proto: yield error on too many gaps in assembler</li> <li>Additional commits viewable in <a href="https://github.com/quinn-rs/quinn/compare/quinn-proto-0.11.14...quinn-proto-0.11.16">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/FuelLabs/sway/network/alerts). </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Igor Rončević <ironcev@hotmail.com> | 23 天前 | |
Remove syntax highlighting of Sway files as Rust (#5926) ## Description Github recognizes Sway files and does not need them to be marked as Rust. | 2 年前 | |
Add `--perf` option to `test` to collect and diff performance data (#7459) ## Description This PR: - Adds `--perf` and `--perf-only` options to `test` to collect gas usages and bytecode sizes, and to run only the tests that actually produce those performance data, respectively. - Adds `[performance]` recipes to `justfile` that fully automate a workflow for collecting and comparing performance data of the compiler output. `--perf` flag instructs `test` to collect performance data from tests of categories `compile`, `run`, and `unit_tests_pass`. Collected gas usages and bytecode sizes are written to files named `<timestamp>-<category>-<build profile>-<branch>.csv`. E.g.: `1020165605-e2e-bytecode-sizes-release-master.csv`. When running tests in parallel (default option), performance data of each individual `test --exact <test_toml_path>` process is written to a piped stdout in JSON format. The main `test` process collects those JSON outputs from all spanned processes. The usual workflow of collecting and comparing performance data between the `master` and feature branch is supported by the following `just` recipes: ```console [performance] perf-e2e filter='' # collect gas usages and bytecode sizes from E2E tests [alias: pe2e] perf-in-lang filter='' # collect gas usages from in-language tests [alias: pil] perf-all filter='' # collect gas usages and bytecode sizes from all tests (E2E and in-language) [alias: pa] perf-diff before after format='md' # generate performance diff between two CSV files [alias: pd] perf-diff-latest format='md' # generate performance diffs between the latest two CSV files per testing category [alias: pdl] perf-snapshot-historical path open='' # collect historic gas usages from a snapshot test that has a `forc test` output [alias: psh] perf-list # list all performance files (*gas-usages-*.* and *bytecode-sizes-*.*) [alias: pl] perf-remove # remove all performance files (*gas-usages-*.* and *bytecode-sizes-*.*) [alias: pr] ``` To obtain the performance comparison it is enough to run: ```console just pa // `just perf-all`. On `master` to get the baseline. just pa // `just perf-all`. On the feature branch to get the improved data. just pdl // `just perf-diff-latest`. To get the diff of the last two collected performance data sets. ``` The `just` recipes should be executed from the root of the Sway repository. Aside from `--perf` writing to predefined files, all other parts of the workflow are `just` recipes and can potentially be tailored to any other workflow. Adding support for collecting gas usages and bytecode sizes from other tests like (snapshot, in-language, SDK harness) will be added in follow up PRs. ## Checklist - [ ] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. | 10 个月前 | |
add docs CI, rename docs README to index (#4874) This PR includes a docs CI to prevent the docs-hub from breaking You can find a README for the CI [here](https://github.com/FuelLabs/github-actions/blob/master/docs-hub/README.md). This replaces the previous markdown lint CI. | 3 年前 | |
add docs CI, rename docs README to index (#4874) This PR includes a docs CI to prevent the docs-hub from breaking You can find a README for the CI [here](https://github.com/FuelLabs/github-actions/blob/master/docs-hub/README.md). This replaces the previous markdown lint CI. | 3 年前 | |
Fix type check issues on CI (#7543) ## Description This PR fixes the current spell checking issues on all open PRs caused by the newest version of `typos`. The PR adds `configurables`, `consts`, and `cpy` to ignore identifiers and also fixes an actual typo in "iterationn". ## 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. | 6 个月前 | |
Bump to 0.72.0 (#7699) ## Description This PR bumps the repo version to a breaking change v0.72.0. ## 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. | 1 个月前 | |
Bump to 0.72.0 (#7699) ## Description This PR bumps the repo version to a breaking change v0.72.0. ## 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. | 1 个月前 | |
Create LICENSE (#452) | 4 年前 | |
One `justfile` to run them all (#7369) ## Description This PR brings all the scripts that we have, and push a couple more into one `just` file (https://github.com/casey/just). Initially we are just calling the script directly, but we can improve it later. ## 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. | 11 个月前 | |
feat: update security policy | 1 年前 | |
ci: fixing typos programmatically (#5975) ## Description Adds a CI check for typos and fixes all* typos in code, comments, and docs. *found by [typos-cli](https://github.com/crate-ci/typos) `typos` doesn't catch everything, but it seems to work better than codespell and cargo-spellcheck (fewer false positives). ## 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. | 2 年前 | |
Refactor and tidy up `std` tests for execution speed and discoverability (#7669) ## Description This PR represents a major cleanup and refactoring of tests covering `std` and closes #7617. The PR brings: - **consistency**: all `std` tests are now in `in_language_tests` and not scattered anymore on four different places (`sway-lib-std`, `stdlib`, `sdk-harness`, and `in_language_tests`). - **better discoverability**: test Sway files have the same name as their tested modules and appear in IDE file searches next to each other. - **better execution speed**: by removing redundant test projects and grouping existing `in_language_tests` projects per tested `std` modules we reduced the number of projects to compile and tests to run noticeably gaining on test execution speed. The above benefits are gained via: - porting E2E `stdlib` tests to `in_language_tests` and deleting redundant test projects. - porting `std` related SDK harness tests to `in_language_tests` and deleting redundant test projects. - moving 11 unit tests found in `sway-lib-std` to `in_language_tests` and forbidding writing unit tests in the `sway-lib-std`. `std` test **must** now be situated in in-language tests. The consequence of this decision is losing the possibility to test private members. Currently this is not a limitation. If it ever becomes, we can allow intentional testing of private members, e.g., via special test naming conventions or some other approach. - restructuring `in_language_tests` for better discoverability and test execution speed. The guidelines for writing in-language tests are fully documented in the accompanied README.md. The PR also acknowledges the control and flexibility we gained by introducing `run_in_language_tests.sh`. Although initially introduced as a workaround for #7613 the script proved to be more powerful and useful for development than using plain `forc test` of the workspace. Therefore, the PR removes TODOs related to switching back to `forc test`ing the whole workspace. The new structure of in-language tests reflects the `std` module structure. Having test modules being named the same as their tested `std` modules allows for quicker finding of both the module and its tests in IDEs. The new convention also removes the verbosity of the `_inline_tests` and `_contract_tests` prefixes. It turned out that this verbose additional information didn't bring a concrete benefit, while producing visual clutter. The faster test execution is noticeable. By grouping several in-language projects into a single one we have less `std` compilations. Number of initial in-language projects dropped from 72 to 47 causing parallel execution time of whole suite to drop from ~55s to ~40s. Similarly, we deleted the following number of other test projects that were redundant and already covered by in-language tests: 1. 35 out of 39 `stdlib` test projects from E2E tests, 1. 8 SDK harness test projects. - Closes #7617. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. | 2 个月前 | |
chore: bumpt rust version to 1.90 (#7427) ## Description Bumping the rust version to 1.90 and fixing the clippy lints along the way | 10 个月前 | |
Refactor `DeclEngine` for robustness and semantic consistency (#7704) ## Description This PR is a prerequisite for an upcoming performance optimization of the `DeclEngine`, aimed at additional removals of copied `TyDecl` entries from the `DeclEngine`. The PR: - properly implements `HasChanges` for `MaterializeConstGenerics::materialize_const_generics`. During compilation of the o2 `order-book` contract, this change removes 104 duplicated function decls and 894 duplicated struct decls. - removes `insert_arc` from the `DeclEngine`. The semantic of this method made no sense for its existing usages. In all usages, we were inserting an existing declaration gotten from the `DeclEngine` and just giving it a different `DeclId`. In other words, calling `DeclEngine::get_...` would for both `DeclId`s return exactly the same declaration. Additionally, all those usages were only in ABI declarations, for ABI's `TyImplItem::Fn/Constant/Type` where none of those can be modified afterwards in any way (e.g., we do not support them being generic in ABIs). As expected, removing `insert_arc` and replacing its returned `DeclRef` with the original didn't change semantic of any calls that were using it. - adds `insert_modified` method to the `DeclEngine` and forces `insert` to provide `ParsedDeclId`. Previous approach in which callers were responsible for either passing the `ParsedDeclId` for the first time or getting it by `get_parsed_decl_id` was both verbose and error-prone. There were cases in code, some even marked with TODO, where the `ParsedDeclId` was not provided when inserting a modified declaration, essentially inserting declarations that were not connected to their parsed equivalents. - adds `insert_dummy_func` method to the `DeclEngine` to clearly distinguish the only case in which a typed declaration does not have the corresponding parsed declaration. - fixes the bug of having two different fields for parsed const generics in the `DeclEngine`: `const_generic_parsed_decl_id_map` and `const_generic**s**_parsed_decl_id_map`. The plural version was used for writing and singular for reading, effectively resulting in const generics never having their corresponding parsed declarations attached. - wires all instances of `ConstGenericParameter` with their corresponding `ParsedDeclId`s. Previously this was done for const generics in functions and impls, but not in structs, enums, and traits. Additionally, the PR: - adds `run-tests.sh` and `just t` recipe for convenient running of the base set of Sway compiler tests. ## Checklist - [ ] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. | 23 天前 | |
chore: rename `fn_args_layout` to `fn_params_layout` in `rustfmt.toml` (#4530) ## Description Since https://github.com/rust-lang/rustfmt/issues/4149 is released with latest rust toolchain 1.69, we are seeing some warnings from rustfmt. This PR addresses the depreciation note in our `rustfmt.toml`. | 3 年前 | |
chore: add a script to bump all fuel maintained dependencies (#6684) ## Description Adds a bash script which iterates over all fuel owned/maintained crates we depend on and only runs cargo update for them. This is especially useful for incorporating minor bumps which happens much more often. Co-authored-by: Joshua Batty <joshpbatty@gmail.com> | 1 年前 |
以下内容由 AI 翻译,如有问题请 点此提交 issue 反馈
Sway
Sway 是为 Fuel 区块链开发的语言。它深受 Rust 的启发,旨在为区块链生态系统带来现代化的语言开发体验和性能。
文档
如需用户文档(包括安装发布版本),请参阅 Sway 手册:https://fuellabs.github.io/sway/latest/。
如需 Sway 标准库文档,请参阅:https://fuellabs.github.io/sway/master/std/
另可查看 Sway 编程语言的技术参考:https://fuellabs.github.io/sway/master/reference/
从源代码构建
本节内容适用于 Sway 编译器和工具链的开发。如需开发合约和使用 Sway,请参阅上述文档部分。
依赖项
Sway 使用 Rust 构建。首先,请按照 https://www.rust-lang.org/tools/install 上的说明安装 Rust 工具链。然后将 Rust 工具链配置为使用 Rust stable 版本:
rustup default stable
如果尚未操作,请将 Cargo 二进制文件目录添加到你的 PATH 中,方法是将以下行添加到 ~/.profile 并重启 shell 会话。
export PATH="${HOME}/.cargo/bin:${PATH}"
构建 Forc
克隆仓库并构建 Sway 工具链:
git clone git@github.com:FuelLabs/sway.git
cd sway
cargo build
确认 Sway 工具链已成功构建:
cargo run --bin forc -- --help
其他所有脚本/命令
对于其他所有脚本和命令,请使用 https://github.com/casey/just:
> just --list
Available recipes:
[automation]
update-contract-ids
update-fuel-dependencies
[benchmark]
benchmark
benchmark-tests
collect-gas-usage
[build]
build-highlightjs
build-prism
generate-sway-lib-std
[ci]
ci-check
install-ci-check
[test]
test-forc-fmt-check-panic
为 Sway 做贡献
我们欢迎大家为 Sway 贡献力量!
有关帮助您入门的指南和说明,请参阅 Sway 手册中的 Contributing To Sway 部分。