| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
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 个月前 | |
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 个月前 | |
Fix `SROA` when loading in multiple blocks (#7694) ## Description Whilst trying to improve https://github.com/FuelLabs/sway/pull/7682, I came across the following bug: SROA was generating invalid IR when an aggregated had `load`s across multiple blocks. When generating the scalar accesses, the older algorithm was gathering only the "last" block that had access, and incorrectly generating `load`s pointing to this last block, even when the `load` was from a previous block. A "use-before-def" problem. (see sway-ir/tests/sroa/cross_block_gep_reuse.ir). To verify this issue this PR also creates an "SSA dominance check". We check if all "uses" are dominated by all its "defs". But this check is expensive, so, for the moment, this check is opt-in. Below we have some timings to justify that: ``` dominance check off: > hyperfine "cargo r -p forc -r -- build --path fuel-o2-exports/contracts/order-book --release" Benchmark 1: cargo r -p forc -r -- build --path fuel-o2-exports/contracts/order-book --release Time (mean ± σ): 11.213 s ± 0.100 s [User: 8.347 s, System: 1.095 s] Range (min … max): 11.105 s … 11.383 s 10 runs dominance check on: > SWAY_FORCE_VERIFY_IR=true hyperfine "cargo r -p forc -r -- build --path fuel-o2-exports/contracts/order-book --release" Benchmark 1: cargo r -p forc -r -- build --path fuel-o2-exports/contracts/order-book --release Time (mean ± σ): 16.663 s ± 0.577 s [User: 13.563 s, System: 1.121 s] Range (min … max): 16.358 s … 18.271 s 10 runs ``` This PR also removes `DCE` and `MEM2REG` passes. from the SROA test. They were there to facilitate `filecheck` directives. As we do not use them anymore, seeing the diff as it is, is actually better. ## 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) - [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: Igor Rončević <ironcev@hotmail.com> | 1 个月前 | |
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> | 25 天前 | |
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 个月前 | |
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 个月前 | |
Bump to 0.70.0 (#7438) Co-authored-by: Igor Rončević <ironcev@hotmail.com> | 10 个月前 | |
Implement dynamic storage based `StorageVec` (#7614) ## Description This PR is an additional step in implementing #7560. It implements `StorageVec<V>` for dynamic storage. Additionally the PR: - adds comprehensive test coverage for `StorageVec` in the form of in-language tests. Existing SDK harness tests are deleted in favor of new in-language tests. This is aligned with the agreed strategy to migrate SDK harness tests to in-language tests. - closes #6040 by properly documenting the semantics of zero-sized types in relation to storage. Every `StorageVec<V>` methods that does not work with zero-sized types, which are assumed to be nested storage types, is now documented for limitations. - fixes #7618 by accepting non-aligned types of any size in `store_vec` and `load_vec` and padding them accordingly. - fixes existing issue of over-allocating memory and having larger amount of slot writes than needed in the quads-based implementation of `store_vec`. - consistently add reverts to all existing `StorageVec<V>` methods in the quads-based implementation that cannot be used with nested storage types. For more details see Breaking Changes below. When running in-language tests using `forc test` on the whole workspace two blocking issues occur: - #7612 - #7613 Workarounds for those issues are commented in code and linked to the issues. Additional in-language tests for other storage types will be added in a separate PR. ## Breaking Changes Existing `StorageVec<V>` methods in the quads-based implementation that cannot be used with nested storage types, e.g., `swap` now consistently reverts if `V` is a nested storage type. Previously, those methods: - sometimes always reverted, - sometimes reverted in specific paths, - sometimes executed with undefined behavior. Consistently reverting can be a breaking change if some existing code called these methods and they were not reverting. Note that such calls represent invalid usage of the storage API (although it was up to now not clearly documented as such) and reverting will actually point to bugs in existing callers code. ## 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. | 3 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 25 天前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 10 个月前 | ||
| 3 个月前 |