Implement `IntoIterator` for our OOM-handling `PrimaryMap` (#12605)

* Implement `IntoIterator` for our OOM-handling `PrimaryMap`

* rustfmt

Remove `cranelift_entity::{Signed, Unsigned}` (#11400)

Use `*::cast_{un,}signed` in the Rust standard library stabilized in
1.87.

Fix name qualification in the `entity_impl` macro. (#10776)

Use `$crate` in the `entity_impl` macro for references to itself, so that
they resolve even if `entity_impl` isn't imported into the globa

Fix name qualification in the `entity_impl` macro. (#10776)

Use `$crate` in the `entity_impl` macro for references to itself, so that
they resolve even if `entity_impl` isn't imported into the global scope.

show more ...

`cranelift-frontend`: Propagate needs-stack-map from variables to values during finalization (#10468)

* cranelift-frontend: Propagate needs-stack-map from variables to values during finalization

Ra

`cranelift-frontend`: Propagate needs-stack-map from variables to values during finalization (#10468)

* cranelift-frontend: Propagate needs-stack-map from variables to values during finalization

Rather than trying to propagate the needs-stack-map bit from variables to values
online, while we are building the IR and defining and using variables, wait
until the function is being finalized, and then propagate everything all at
once. This avoids potential repeated work and is easier to ensure that it is
complete and covers all values associated with a variable, since by the time we
are finalizing the function, we won't add any new values for a variable that we
will need to keep track of and propagate this information to.

This also means that we can remove the `params_added_to_blocks` vector from the
SSA side effects structure, since it was only used to online-update the
`stack_map_values` set.

* Initialize the env-logger in `#[wasmtime_test]`

* Fix needs-stack-map set iteration

For reasons I do not understand, the `EntitySet::keys` method includes keys that
are not in the set, and we have unit tests asserting this bizarre behavior. Very
perplexing. So I added a new method to iterate over just the elements of the
set.

show more ...

refactor: unify how bits are accessed in `cranelift-entity` (#10126)

* refactor: unify how bits are accessed in `cranelift-entity`

While using `MachLabel`, a `cranelift-entity`-created type, I noti

refactor: unify how bits are accessed in `cranelift-entity` (#10126)

* refactor: unify how bits are accessed in `cranelift-entity`

While using `MachLabel`, a `cranelift-entity`-created type, I noticed
that there were three ways to access the contained bits: `.get()`,
`.as_u32()`, and `.as_bits()`. All performed essentially the same
function and it was unclear which to use.

This change removes `MachLabel::get()`, replacing it with `as_u32()`.
It also replaces all uses of `from_bits()` and `as_bits()` with
`from_u32()` and `as_u32()`. Why? I would have preferred the "bits"
naming since it seems more clear ("just unwrap this thing") and it could
avoid a large rename if the type were changed in the future, I realized
that there are vastly more uses of the "u32" naming that already
exist--it's just easier.

While this refactoring _should_ result in no functional change, you may
notice a couple of failing tests related to a pre-existing check on
`from_u32` that did not exist on `from_bits`. For some reason,
`from_u32` asserted that we would never pick `u32::MAX` for an entity
value; unfortunately, some parsing code, `decode_narrow_field`, does
just this. Why did we have such an assertion in the first place? Is it
still needed? Should `decode_narrow_field` do something else?

* Re-add `from_bits`, `as_bits` and uses

* doc: tweak doc comment

show more ...

Start using `#[expect]` instead of `#[allow]` (#9696)

* Start using `#[expect]` instead of `#[allow]`

In Rust 1.81, our new MSRV, a new feature was added to Rust to use
`#[expect]` to control lint

Start using `#[expect]` instead of `#[allow]` (#9696)

* Start using `#[expect]` instead of `#[allow]`

In Rust 1.81, our new MSRV, a new feature was added to Rust to use
`#[expect]` to control lint levels. This new lint annotation will
silence a lint but will itself cause a lint if it doesn't actually
silence anything. This is quite useful to ensure that annotations don't
get stale over time.

Another feature is the ability to use a `reason` directive on the
attribute with a string explaining why the attribute is there. This
string is then rendered in compiler messages if a warning or error
happens.

This commit migrates applies a few changes across the workspace:

* Some `#[allow]` are changed to `#[expect]` with a `reason`.
* Some `#[allow]` have a `reason` added if the lint conditionally fires
(mostly related to macros).
* Some `#[allow]` are removed since the lint doesn't actually fire.
* The workspace configures `clippy::allow_attributes_without_reason = 'warn'`
as a "ratchet" to prevent future regressions.
* Many crates are annotated to allow `allow_attributes_without_reason`
during this transitionary period.

The end-state is that all crates should use
`#[expect(..., reason = "...")]` for any lint that unconditionally fires
but is expected. The `#[allow(..., reason = "...")]` lint should be used
for conditionally firing lints, primarily in macro-related code.
The `allow_attributes_without_reason = 'warn'` level is intended to be
permanent but the transitionary
`#[expect(clippy::allow_attributes_without_reason)]` crate annotations
to go away over time.

* Fix adapter build

prtest:full

* Fix one-core build of icache coherence

* Use `allow` for missing_docs

Work around rust-lang/rust#130021 which was fixed in Rust 1.83 and isn't
fixed for our MSRV at this time.

* More MSRV compat

show more ...

Add a `Signed` trait to match the `Unsigned` trait (#9232)

* Add a `Signed` trait to match the `Unsigned` trait

I've wanted to use this every now and then but haven't gotten around to
adding this s

Add a `Signed` trait to match the `Unsigned` trait (#9232)

* Add a `Signed` trait to match the `Unsigned` trait

I've wanted to use this every now and then but haven't gotten around to
adding this so figured I'd go ahead and add it.

* Update cranelift/entity/src/signed.rs

Co-authored-by: Nick Fitzgerald <[email protected]>

---------

Co-authored-by: Nick Fitzgerald <[email protected]>

show more ...

Enforce `uninlined_format_args` for the workspace (#9065)

* Enforce `uninlined_format_args` for the workspace

* fix: failing `Monolith Checks` job

* fix: formatting

Add support for recursion groups in the types registry (#8404)

Configure workspace lints, enable running some Clippy lints on CI (#7561)

* Configure Rust lints at the workspace level

This commit adds necessary configuration knobs to have lints configured
at th

Configure workspace lints, enable running some Clippy lints on CI (#7561)

* Configure Rust lints at the workspace level

This commit adds necessary configuration knobs to have lints configured
at the workspace level in Wasmtime rather than the crate level. This
uses a feature of Cargo first released with 1.74.0 (last week) of the
`[workspace.lints]` table. This should help create a more consistent set
of lints applied across all crates in our workspace in addition to
possibly running select clippy lints on CI as well.

* Move `unused_extern_crates` to the workspace level

This commit configures a `deny` lint level for the
`unused_extern_crates` lint to the workspace level rather than the
previous configuration at the individual crate level.

* Move `trivial_numeric_casts` to workspace level

* Change workspace lint levels to `warn`

CI will ensure that these don't get checked into the codebase and
otherwise provide fewer speed bumps for in-process development.

* Move `unstable_features` lint to workspace level

* Move `unused_import_braces` lint to workspace level

* Start running Clippy on CI

This commit configures our CI to run `cargo clippy --workspace` for all
merged PRs. Historically this hasn't been all the feasible due to the
amount of configuration required to control the number of warnings on
CI, but with Cargo's new `[lint]` table it's possible to have a
one-liner to silence all lints from Clippy by default. This commit by
default sets the `all` lint in Clippy to `allow` to by-default disable
warnings from Clippy. The goal of this PR is to enable selective access
to Clippy lints for Wasmtime on CI.

* Selectively enable `clippy::cast_sign_loss`

This would have fixed #7558 so try to head off future issues with that
by warning against this situation in a few crates. This lint is still
quite noisy though for Cranelift for example so it's not worthwhile at
this time to enable it for the whole workspace.

* Fix CI error

prtest:full

show more ...

Remove clippy configuration from repo and crates (#6927)

Wasmtime's CI does not run clippy so there's no enforcement of this
configuration. Additionally the configuration per-crate is not uniformly

Remove clippy configuration from repo and crates (#6927)

Wasmtime's CI does not run clippy so there's no enforcement of this
configuration. Additionally the configuration per-crate is not uniformly
applied across all of the Wasmtime workspace and is only on some
historical crates. Because we don't run clippy in CI this commit removes
all of the clippy annotations for allow/warn/deny from the source.

show more ...

Fix tests in `--release` mode (#6308)

Add `#[cfg]` annotations to some tests which rely on `debug_assert!` for
panics.

Cranelift: support 14-bit Type index with some bitpacking. (#4269)

* Cranelift: make `ir::Type` a `u16`.

* Cranelift: pack ValueData back into 64 bits.

After extending `Type` to a `u16`, `Valu

Cranelift: support 14-bit Type index with some bitpacking. (#4269)

* Cranelift: make `ir::Type` a `u16`.

* Cranelift: pack ValueData back into 64 bits.

After extending `Type` to a `u16`, `ValueData` became 12 bytes rather
than 8. This packs it back down to 8 bytes (64 bits) by stealing two
bits from the `Type` for the enum discriminant (leaving 14 bits for the
type itself).

Performance comparison (3-way between original (`ty-u8`), 16-bit `Type`
(`ty-u16`), and this PR (`ty-packed`)):

```
~/work/sightglass% target/release/sightglass-cli benchmark \
-e ~/ty-u8.so -e ~/ty-u16.so -e ~/ty-packed.so \
--iterations-per-process 10 --processes 2 \
benchmarks-next/spidermonkey/benchmark.wasm

compilation
benchmarks-next/spidermonkey/benchmark.wasm
cycles
[20654406874 21749213920.50 22958520306] /home/cfallin/ty-packed.so
[22227738316 22584704883.90 22916433748] /home/cfallin/ty-u16.so
[20659150490 21598675968.60 22588108428] /home/cfallin/ty-u8.so
nanoseconds
[5435333269 5723139427.25 6041072883] /home/cfallin/ty-packed.so
[5848788229 5942729637.85 6030030341] /home/cfallin/ty-u16.so
[5436002390 5683248226.10 5943626225] /home/cfallin/ty-u8.so
```

So, when compiling SpiderMonkey.wasm, making `Type` 16 bits regresses
performance by 4.5% (5.683s -> 5.723s), while this PR gets 14 bits for a 1.0%
cost (5.683s -> 5.723s). That's still not great, and we can likely do better,
but it's a start.

* Fix test failure: entities to/from u32 via `{from,to}_bits`, not `{from,to}_u32`.

show more ...

�� rust fmt

✅ add test cases for new `entity_impl!` form

�� provide a new form of `entity_impl!`

N.B. There is likely still some light refactoring to do, so that we are
not duplicating so much code. We should also additionally introduce some
test coverage.

�� add simple entity tests

Add some more `#[inline]` annotations for trivial functions (#2817)

Looking at some profiles these or their related functions were all
showing up, so this commit adds `#[inline]` to allow cross-cra

Add some more `#[inline]` annotations for trivial functions (#2817)

Looking at some profiles these or their related functions were all
showing up, so this commit adds `#[inline]` to allow cross-crate
inlining by default.

show more ...

Update clippy annotation to use latest version (#2375)

Fix typo in generated documentation for `entity!` (#2176)

* entity: Fix typo in generated documentation

The same function documentation was used for `from_u32()` and `as_u32()`
while their behav

Fix typo in generated documentation for `entity!` (#2176)

* entity: Fix typo in generated documentation

The same function documentation was used for `from_u32()` and `as_u32()`
while their behaviour is different

show more ...

Remove Eq bound of ReservedValue trait

A full Eq implementation is no needed for ReservedValue, as we only need
to check whether a value is the reserved one. For entities (defined with
`entity_impl!

Remove Eq bound of ReservedValue trait

A full Eq implementation is no needed for ReservedValue, as we only need
to check whether a value is the reserved one. For entities (defined with
`entity_impl!`) this doesn't make much difference, but for more
complicated types this avoids generating redundant `Eq`s.

show more ...

Mass rename Ebb and relatives to Block (#1365)

* Manually rename BasicBlock to BlockPredecessor

BasicBlock is a pair of (Ebb, Inst) that is used to represent the
basic block subcomponent of an E

Mass rename Ebb and relatives to Block (#1365)

* Manually rename BasicBlock to BlockPredecessor

BasicBlock is a pair of (Ebb, Inst) that is used to represent the
basic block subcomponent of an Ebb that is a predecessor to an Ebb.

Eventually we will be able to remove this struct, but for now it
makes sense to give it a non-conflicting name so that we can start
to transition Ebb to represent a basic block.

I have not updated any comments that refer to BasicBlock, as
eventually we will remove BlockPredecessor and replace with Block,
which is a basic block, so the comments will become correct.

* Manually rename SSABuilder block types to avoid conflict

SSABuilder has its own Block and BlockData types. These along with
associated identifier will cause conflicts in a later commit, so
they are renamed to be more verbose here.

* Automatically rename 'Ebb' to 'Block' in *.rs

* Automatically rename 'EBB' to 'block' in *.rs

* Automatically rename 'ebb' to 'block' in *.rs

* Automatically rename 'extended basic block' to 'basic block' in *.rs

* Automatically rename 'an basic block' to 'a basic block' in *.rs

* Manually update comment for `Block`

`Block`'s wikipedia article required an update.

* Automatically rename 'an `Block`' to 'a `Block`' in *.rs

* Automatically rename 'extended_basic_block' to 'basic_block' in *.rs

* Automatically rename 'ebb' to 'block' in *.clif

* Manually rename clif constant that contains 'ebb' as substring to avoid conflict

* Automatically rename filecheck uses of 'EBB' to 'BB'

'regex: EBB' -> 'regex: BB'
'$EBB' -> '$BB'

* Automatically rename 'EBB' 'Ebb' to 'block' in *.clif

* Automatically rename 'an block' to 'a block' in *.clif

* Fix broken testcase when function name length increases

Test function names are limited to 16 characters. This causes
the new longer name to be truncated and fail a filecheck test. An
outdated comment was also fixed.

show more ...

Fix clippy warnings.

This commit fixes the current set of (stable) clippy warnings in the repo.

Remove std feature from cranelift-entity

upgrade to target-lexicon 0.8.0

* the target-lexicon crate no longer has or needs the std feature
in cargo, so we can delete all default-features=false, any mentions
of its std feature, and the

upgrade to target-lexicon 0.8.0

* the target-lexicon crate no longer has or needs the std feature
in cargo, so we can delete all default-features=false, any mentions
of its std feature, and the nostd configs in many lib.rs files
* the representation of arm architectures has changed, so some case
statements needed refactoring

show more ...