Latest Results
Refactor `DeclEngine` for robustness and semantic consistency (#7704)
## Description
This PR is a prerequisite for an upcoming performance optimization of
the `DeclEngine`, aimed at additional removals of copied `TyDecl`
entries from the `DeclEngine`.
The PR:
- properly implements `HasChanges` for
`MaterializeConstGenerics::materialize_const_generics`. During
compilation of the o2 `order-book` contract, this change removes 104
duplicated function decls and 894 duplicated struct decls.
- removes `insert_arc` from the `DeclEngine`. The semantic of this
method made no sense for its existing usages. In all usages, we were
inserting an existing declaration gotten from the `DeclEngine` and just
giving it a different `DeclId`. In other words, calling
`DeclEngine::get_...` would for both `DeclId`s return exactly the same
declaration. Additionally, all those usages were only in ABI
declarations, for ABI's `TyImplItem::Fn/Constant/Type` where none of
those can be modified afterwards in any way (e.g., we do not support
them being generic in ABIs). As expected, removing `insert_arc` and
replacing its returned `DeclRef` with the original didn't change
semantic of any calls that were using it.
- adds `insert_modified` method to the `DeclEngine` and forces `insert`
to provide `ParsedDeclId`. Previous approach in which callers were
responsible for either passing the `ParsedDeclId` for the first time or
getting it by `get_parsed_decl_id` was both verbose and error-prone.
There were cases in code, some even marked with TODO, where the
`ParsedDeclId` was not provided when inserting a modified declaration,
essentially inserting declarations that were not connected to their
parsed equivalents.
- adds `insert_dummy_func` method to the `DeclEngine` to clearly
distinguish the only case in which a typed declaration does not have the
corresponding parsed declaration.
- fixes the bug of having two different fields for parsed const generics
in the `DeclEngine`: `const_generic_parsed_decl_id_map` and
`const_generic**s**_parsed_decl_id_map`. The plural version was used for
writing and singular for reading, effectively resulting in const
generics never having their corresponding parsed declarations attached.
- wires all instances of `ConstGenericParameter` with their
corresponding `ParsedDeclId`s. Previously this was done for const
generics in functions and impls, but not in structs, enums, and traits.
Additionally, the PR:
- adds `run-tests.sh` and `just t` recipe for convenient running of the
base set of Sway compiler tests.
## Checklist
- [ ] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers. Implement `__mem_rep_eq` intrinsic (#7697)
## Description
This PR introduces a new `__mem_repr_eq` intrinsic for comparing memory
representation of types, and removes the existing `__runtime_mem_id` and
`__encoding_mem_id` intrinsics.
We decided to introduce `__mem_repr_eq` to mitigate the following issues
we had with existing intrinsics:
- `mem_id`s were `u64` values computed using `DefaultHasher` whose
results are not guaranteed to be stable across different runs of the
same Sway compiler or being same on different target architectures.
- even if we switched to a stable hasher, hashing to `u64` was not
giving a strong no-collision guarantee. A hash collision between
different, e.g. runtime and encoding representation, would in case of
false positives result in wrong encoding or decoding.
The `__mem_repr_eq` is defined as:
```sway
__mem_repr_eq<T>(repr_a: str, repr_b: str) -> bool
```
It returns `true` if the memory representation `repr_a` of the type `T`
is equal to its memory representation `repr_b`, assuming `T` has both
memory representations. If `T` does not have any of the representations
`repr_a` or `repr_b`, returns `false`.
The valid values for `repr_a` and `repr_b` are `"runtime"`,
`"encoding"`, and `"hashing"`:
- `"runtime"` is how the type is represented inside the VM's memory.
This is the Sway runtime memory representation (e.g., struct fields are
aligned to word boundaries, arrays are packed, etc.). This memory
representation is defined for every type.
- `"encoding"` is the packed memory representation of a type, as defined
by the canonical ABI encoding. Not all types have a canonical ABI
encoding defined, e.g., dynamic types like `Vec` or `raw_slice`. In that
case, `"encoding"` never compares equal to any other memory
representation, __including to itself__.
- `"hashing"` is the packed memory representation of a type, as defined
by the canonical hashing introduced in #7695. Not all types have a
canonical hashing defined, e.g., dynamic types like `Vec` or
`raw_slice`. In that case, `"hashing"` never compares equal to any other
memory representation, __including to itself__.
To test if a type `T` has `"encoding"` or `"hashing"` memory
representation defined, compare that representation to itself. E.g.:
`let has_encoding_repr = __mem_repr_eq<T>("encoding", "encoding");`
`repr_a` and `repr_b` must be compile-time constant `str`s, whose values
are one of `"runtime"`, `"encoding"`, or `"hashing"`. The constant
`str`s never end up in the bytecode.
Additionally, the PR moves existing E2E intrinsics tests that were not
in the `language/intrinsics` into `language/intrinsics`.
## Breaking Change
The old `__runtime_mem_id` and `__encoding_mem_id` intrinsics are
removed. The code that is using them must switch to the new
`__mem_repr_eq`.
## 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.
- [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. Latest Branches
0%
ironcev/decl-engine-refactoring 0%
ironcev/rollout-block-is-entry 0%
ironcev/mem-repr-id-intrinsics © 2026 CodSpeed Technology