| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
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 个月前 | |
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 个月前 | |
Issue#3044 Update minor mistakes in README.md and src/reentrancy.sw (#3045) Closes #3044 | 3 年前 | |
Extract all perf data from in-language tests run in parallel (#7670) ## Description This PR: - implements extraction of performance data from in-language tests when they are run in parallel. - implements extraction of bytecode sizes from in-language tests. - fixes the `--filter` passing issue in `justfile` discussed in https://github.com/FuelLabs/sway/pull/7669#discussion_r3488023317. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. | 2 个月前 | |
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 个月前 |
Sway Standard Library
The Sway Standard Library is the foundation of portable Sway software, a set of minimal shared abstractions for the broader Sway ecosystem. It offers core types, like Result<T, E> and Option<T>, library-defined operations on language primitives, native asset management, blockchain contextual operations, access control, storage management, and support for types from other VMs, among many other things.
Usage
The standard library is made implicitly available to all Forc projects created using forc new. In other words, it is not required to manually specify std as an explicit dependency. Forc will automatically use the version of std that matches its version.
Importing items from the standard library can be done using the use keyword, just as importing items from any other Sway library. For example:
use std::storage::StorageMap;
This imports the StorageMap type into the current namespace.
The standard library comes with a "prelude" which is a list of things that Sway automatically imports into every Sway program. It's kept as small as possible, and is focused on things which are used in almost every single Sway program.