| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
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 个月前 | |
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 个月前 | |
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 个月前 | |
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 个月前 | |
Optimize dynamic `std` types (#7683) ## Description This PR optimizes several aspects of dynamic `std` types: - Hashing of string arrays, by properly accommodating initial `Hasher` buffer capacity for the string length prefix. - `Bytes::clear`, by reusing the already allocated buffer, the same way `Vec` is doing it. - Removing expensive double-allocation and memory-copy in the `Bytes::append_raw_slice`. - Adding `from_moved_...` constructors to types that own their buffers, for supporting taking ownership of the content without copying it. - Adding `from_ascii_str_array` constructor to `String` to create a string directly from string array without a need to first copy it to `str` via `from_str_array`. Additionally, the PR: - fixes invalid doc-comment examples on `String` methods, that were using a non-existing `String::push` method. ## Performance Improvements Performance improvements are given in the comment below. Although the PR obviously only removes runtime overhead, we still have some smaller numbers of regressions. Regressions are analyzed and have the same root-cause, the one we already encountered before. The leaner `Bytes::append_raw_slice` now leads to more inlining in hashing code like `sha256` that brings `CastPtr` to caller scope suppressing potential optimizations in the caller. The regressions on real-life o2 code are small and in contract methods that are not frequently used while improvements are bigger and in often use contract methods. Improving this particular issue will be done in #7492. Also, analysis of regressions in `sha256` and `keccak256` calls revealed another potentially high future performance improvement. E.g., hashing a `b256` using `s256` opcode directly costs ~60 gas units, while using `sha256` function will cost ~250 gas units. Similar values for are for `u8`, .., `u256` and even worse for larger structured types. One way to improve our hashing abstractions is to introduce a concept of "trivially hashable types", similar to trivially encodeable and decodeable. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. | 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 个月前 | |
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 个月前 | |
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 个月前 | |
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 个月前 | |
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 个月前 | |
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 个月前 | |
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 个月前 | |
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 个月前 | |
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 个月前 | |
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 dynamic `std` types (#7683) ## Description This PR optimizes several aspects of dynamic `std` types: - Hashing of string arrays, by properly accommodating initial `Hasher` buffer capacity for the string length prefix. - `Bytes::clear`, by reusing the already allocated buffer, the same way `Vec` is doing it. - Removing expensive double-allocation and memory-copy in the `Bytes::append_raw_slice`. - Adding `from_moved_...` constructors to types that own their buffers, for supporting taking ownership of the content without copying it. - Adding `from_ascii_str_array` constructor to `String` to create a string directly from string array without a need to first copy it to `str` via `from_str_array`. Additionally, the PR: - fixes invalid doc-comment examples on `String` methods, that were using a non-existing `String::push` method. ## Performance Improvements Performance improvements are given in the comment below. Although the PR obviously only removes runtime overhead, we still have some smaller numbers of regressions. Regressions are analyzed and have the same root-cause, the one we already encountered before. The leaner `Bytes::append_raw_slice` now leads to more inlining in hashing code like `sha256` that brings `CastPtr` to caller scope suppressing potential optimizations in the caller. The regressions on real-life o2 code are small and in contract methods that are not frequently used while improvements are bigger and in often use contract methods. Improving this particular issue will be done in #7492. Also, analysis of regressions in `sha256` and `keccak256` calls revealed another potentially high future performance improvement. E.g., hashing a `b256` using `s256` opcode directly costs ~60 gas units, while using `sha256` function will cost ~250 gas units. Similar values for are for `u8`, .., `u256` and even worse for larger structured types. One way to improve our hashing abstractions is to introduce a concept of "trivially hashable types", similar to trivially encodeable and decodeable. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. | 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 个月前 | |
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 个月前 | |
Optimize dynamic `std` types (#7683) ## Description This PR optimizes several aspects of dynamic `std` types: - Hashing of string arrays, by properly accommodating initial `Hasher` buffer capacity for the string length prefix. - `Bytes::clear`, by reusing the already allocated buffer, the same way `Vec` is doing it. - Removing expensive double-allocation and memory-copy in the `Bytes::append_raw_slice`. - Adding `from_moved_...` constructors to types that own their buffers, for supporting taking ownership of the content without copying it. - Adding `from_ascii_str_array` constructor to `String` to create a string directly from string array without a need to first copy it to `str` via `from_str_array`. Additionally, the PR: - fixes invalid doc-comment examples on `String` methods, that were using a non-existing `String::push` method. ## Performance Improvements Performance improvements are given in the comment below. Although the PR obviously only removes runtime overhead, we still have some smaller numbers of regressions. Regressions are analyzed and have the same root-cause, the one we already encountered before. The leaner `Bytes::append_raw_slice` now leads to more inlining in hashing code like `sha256` that brings `CastPtr` to caller scope suppressing potential optimizations in the caller. The regressions on real-life o2 code are small and in contract methods that are not frequently used while improvements are bigger and in often use contract methods. Improving this particular issue will be done in #7492. Also, analysis of regressions in `sha256` and `keccak256` calls revealed another potentially high future performance improvement. E.g., hashing a `b256` using `s256` opcode directly costs ~60 gas units, while using `sha256` function will cost ~250 gas units. Similar values for are for `u8`, .., `u256` and even worse for larger structured types. One way to improve our hashing abstractions is to introduce a concept of "trivially hashable types", similar to trivially encodeable and decodeable. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. | 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 个月前 | |
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 个月前 | |
Optimize dynamic `std` types (#7683) ## Description This PR optimizes several aspects of dynamic `std` types: - Hashing of string arrays, by properly accommodating initial `Hasher` buffer capacity for the string length prefix. - `Bytes::clear`, by reusing the already allocated buffer, the same way `Vec` is doing it. - Removing expensive double-allocation and memory-copy in the `Bytes::append_raw_slice`. - Adding `from_moved_...` constructors to types that own their buffers, for supporting taking ownership of the content without copying it. - Adding `from_ascii_str_array` constructor to `String` to create a string directly from string array without a need to first copy it to `str` via `from_str_array`. Additionally, the PR: - fixes invalid doc-comment examples on `String` methods, that were using a non-existing `String::push` method. ## Performance Improvements Performance improvements are given in the comment below. Although the PR obviously only removes runtime overhead, we still have some smaller numbers of regressions. Regressions are analyzed and have the same root-cause, the one we already encountered before. The leaner `Bytes::append_raw_slice` now leads to more inlining in hashing code like `sha256` that brings `CastPtr` to caller scope suppressing potential optimizations in the caller. The regressions on real-life o2 code are small and in contract methods that are not frequently used while improvements are bigger and in often use contract methods. Improving this particular issue will be done in #7492. Also, analysis of regressions in `sha256` and `keccak256` calls revealed another potentially high future performance improvement. E.g., hashing a `b256` using `s256` opcode directly costs ~60 gas units, while using `sha256` function will cost ~250 gas units. Similar values for are for `u8`, .., `u256` and even worse for larger structured types. One way to improve our hashing abstractions is to introduce a concept of "trivially hashable types", similar to trivially encodeable and decodeable. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. | 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 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 1 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 |