| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
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 个月前 | |
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 个月前 | |
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> | 26 天前 | |
Update `fuel-vm` and `fuels` dependencies in `sdk-harness` tests (#7591) ## Description This PR updates the `fuel-vm` and `fuels` dependencies in `sdk-harness` tests to the same versions used in the rest of the Sway repository. The PR extends the `check-sdk-harness-version.sh` script to also be able to check the `fuel-vm` and `fuels` dependencies, and adds those to the `PACKAGE_NAMES` to be checked in the CI step. ## 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. | 4 个月前 | |
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 个月前 | |
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 个月前 | |
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 年前 |
Building & running the sway-lib-std tests
Building test projects
Compile all the Sway programs in the workspace as follows:
# from project root
cargo run --bin=forc build --path test/src/sdk-harness
This will build all contracts and scripts under the sway/test/src/sdk-harness directory.
After a successful build of all the projects:
cargo test
For more on the usage of Forc for testing, see: https://fuellabs.github.io/sway/master/book/forc/commands/forc_test.html