Latest Results
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. Remove cloning of parsed tree elements during type checking (#7667)
## Description
This PR removes excessive unnecessary cloning of parsed tree elements
(parsed declarations and expressions) during type checking.
Removing cloning further reduces compilation time of the `order-book`
contract **from ~4.3 to ~4.1 seconds**.
Here is the number of `clone()` calls (taken from the `order-book`
contract) for several parsed tree elements, _given just for the highest
levels of transformation_:
| Parsed element | Number of `clone()`s |
| ---------------------------- | -------------------: |
| AstNodeContent | 23778 |
| VariableDeclaration | 9321 |
| ImplSelfOrTrait | 1244 |
| ConstantDeclaration | 308 |
| StructDeclaration | 104 |
| EnumDeclaration | 48 |
| TraitDeclaration | 43 |
| AbiDeclaration | 27 |
| ConfigurableDeclaration | 22 |
Note that these is only the cloning at the highest level of
transformation from the parsed to typed tree. **Those cloned element or
their contained elements were later repeatedly cloned on lower steps,
especially parsed `Expression`s.**
When creating final typed tree elements, we still clone some parts of
their corresponding parsed tree elements. Those are mostly `Span`s,
`Attributes` (only `Arc` clone), and `Indent`s. Removing those clones
would require additional changes in the compiler architecture, and at
least for cheep clones like `Span`s and `Arc`s it wouldn't bring much.
E.g., see: #6602. The goal of this PR was to remove unnecessary
double-cloning of parsed elements, where the final (cheeper) clones
taken into typed tree were cloned from expensive parsed element clones.
Additionally, the PR:
- removes additional unnecessary `clone()` calls unrelated to cloning of
parsed declarations.
- changes `collect` for `Expression` to always bail out on first error.
This behavior was inconsistent for different `ExpressionKind`s. We might
consider doing it other way around continuing collections on errors, but
it must be consistent for all `ExpressionKind`s. (Note that only
`TyCodeBlock::collect` actually collects, and always returns `Ok`.)
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers. Latest Branches
-16%
ironcev/refactor-std-tests +24%
ironcev/remove-cloning-of-parsed-declarations +25%
xunilrj/fix-opt-passes-convergence © 2026 CodSpeed Technology