Latest Results
Optionally print IR metadata block (#7684)
## Description
This PR makes printing of the IR metadata block optional.
For IR analysis, in most of the cases, the printed IR just introduces
clutter. It is now not printed by default. To print it, `print-md`
directive must be added to the `--ir` CLI argument (or `--print-ir` in
E2E tests). E.g.:
```
--ir all modified print-md
--if final print-md
```
IR metadata is removed from almost all the snapshots, except the two
that use the whole `sway-lib-std`. Seeing changes in metadata when
changing `std` code is still useful.
The `filter-fn` option in snapshot tests was previously relying on the
first `!0` as an end of the printed IR step. This is now changed to
checking for a `}` in at the beginning of a line.
## Breaking Change
Strictly seen, this is a breaking change, in case someone prints IR and
relies on having metadata printed.
## Checklist
- [ ] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers. 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. Latest Branches
+25%
0%
ironcev/optionally-print-ir-metadata 0%
© 2026 CodSpeed Technology