assert more in release in `rustc_ast_lowering`
My understanding of the compiler's architecture is that in the `ast_lowering` crate, we are constructing the HIR as a one-time thing per crate. This is after tokenizing, parsing, resolution, expansion, possible reparsing, reresolution, reexpansion, and so on. In other words, there are many reasons that perf-focused PRs spend a lot of time touching `rustc_parse`, `rustc_expand`, `rustc_ast`, and then `rustc_hir` and "onwards", but `ast_lowering` is a little bit of an odd duck.
In this crate, we have a number of debug assertions. Some are clearly expensive checks that seem like they are prohibitive to run in actual optimized compiler builds, but then there are a number that are simple asserts on integer equalities, `is_empty`, or the like. I believe we should do some of them even in release builds, because the correctness gain is worth the performance cost: almost zero.
tests: Split dont-shuffle-bswaps along opt-levels and arches
This duplicates dont-shuffle-bswaps in order to make each opt level its own test. Then -opt3.rs gets split into a revision per arch we want to test, with certain architectures gaining new target-cpu minimums.
add `extern "custom"` functions
tracking issue: rust-lang/rust#140829
previous discussion: https://github.com/rust-lang/rust/issues/140566
In short, an `extern "custom"` function is a function with a custom ABI, that rust does not know about. Therefore, such functions can only be defined with `#[unsafe(naked)]` and `naked_asm!`, or via an `extern "C" { /* ... */ }` block. These functions cannot be called using normal rust syntax: calling them can only be done from inline assembly.
The motivation is low-level scenarios where a custom calling convention is used. Currently, we often pick `extern "C"`, but that is a lie because the function does not actually respect the C calling convention.
At the moment `"custom"` seems to be the name with the most support. That name is not final, but we need to pick something to actually implement this.
r? `@traviscross`
cc `@tgross35`
try-job: x86_64-apple-2
retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features
`-Zretpoline` and `-Zretpoline-external-thunk` flags are target modifiers (tracked to be equal in linked crates).
* Enables target features for `-Zretpoline-external-thunk`:
`+retpoline-external-thunk`, `+retpoline-indirect-branches`, `+retpoline-indirect-calls`.
* Enables target features for `-Zretpoline`:
`+retpoline-indirect-branches`, `+retpoline-indirect-calls`.
It corresponds to clang -mretpoline & -mretpoline-external-thunk flags.
Also this PR forbids to specify those target features manually (warning).
Issue: rust-lang/rust#116852
Apply nested goals certainty to `InspectGoals` for normalizes-to
...so that normalizes-to goals don't have `Certainty::Yes` even if they have nested goals which don't hold.
r? lcnr
Faster fmt::Display of 128-bit integers, without unsafe pointer
In followup of #135265, hereby the 128-bit part.
* Batches per 16 instead of 19 digits
* Buffer access as array insteaf of unsafe pointer
* Added test coverage for i128 and u128
r? tgross35 ChrisDenton
feat: Add `bit_width` for unsigned integer types
- Accepted ACP: rust-lang/libs-team#598
- Tracking issue: rust-lang/rust#142326
This PR adds methods to the primitive unsigned integer types that return the minimum number of bits required to represent an unsigned integer.
Implement `//@ needs-target-std` compiletest directive
Closesrust-lang/rust#141863.
Needed to unblock rust-lang/rust#139244 and rust-lang/rust#141856.
### Summary
This PR implements a `//@ needs-target-std` compiletest directive that gates test execution based on whether the target supports std or not. For some cases, this should be preferred over e.g. some combination of `//@ ignore-none`, `//@ ignore-nvptx` and more[^none-limit].
### Implementation limitation
Unfortunately, since there is currently [no reliable way to determine from metadata whether a given target supports std or not](https://github.com/rust-lang/rust/issues/142296), we have to resort to a hack. Bootstrap currently determines whether or not a target supports std by a naive target tuple substring comparison: a target supports std if its target tuple does *not* contain one of `["-none", "nvptx", "switch"]` substrings. This PR simply pulls that hack out into `build_helpers` to avoid reimplementing the same hack in compiletest, and uses that logic to inform `//@ needs-target-std`.
### Auxiliary changes
This PR additionally changes a few run-make tests to use `//@ needs-target-std` over an inconsistent combination of target-based `ignore`s. This should help with rust-lang/rust#139244.
---
r? bootstrap
[^none-limit]: Notably, `target_os = "none"` is **not** a sufficient condition for "target does not support std"
Make root vars more stable
Never resolve a ty/ct vid to a higher vid as its root. This should make the optimization in rust-lang/rust#141500 more "stable" when there are a lot of vars flying around.
r? `@ghost`
mir-opt: Do not create storage marks in EarlyOtherwiseBranch
Fixes#141212.
The first commit add `StorageDead` by creating new indirect BB that makes CFG more complicated, but I think it's better to just not create storage marks.
r? mir-opt
Update cargo
18 commits in 64a12460708cf146e16cc61f28aba5dc2463bbb4..fc1518ef02b77327d70d4026b95ea719dd9b8c51
2025-05-30 18:25:08 +0000 to 2025-06-06 04:49:44 +0000
- fix: Make UI tests handle hyperlinks consistently (rust-lang/cargo#15640)
- Update "time out" to "timeout" (rust-lang/cargo#15637)
- fix(workspace): reload current manifest path member only (rust-lang/cargo#15633)
- Update dependencies (rust-lang/cargo#15635)
- fix(publish): Don't tell people to ctrl-c without knowing consequences (rust-lang/cargo#15632)
- refactor: clean up `clippy::perf` lint warnings (rust-lang/cargo#15631)
- fix(package): Skip registry check if its not needed (rust-lang/cargo#15629)
- Add --offline for comp (rust-lang/cargo#15623)
- cargo-credential-libsecret: load libsecret only once (rust-lang/cargo#15295)
- test(publish): Improvements in prep for `-Zpackage-workspace` stabilization (rust-lang/cargo#15628)
- fix(package): Allow packaging of self-cycles with -Zpackage-workspace (rust-lang/cargo#15626)
- docs: clarify `--all-features` not available for all commmands (rust-lang/cargo#15572)
- Remove double reference in Shell::print_json (rust-lang/cargo#15460)
- fix(trim-paths): remap all paths to `build.build-dir` (rust-lang/cargo#15614)
- test(trim-paths): enable more tests for windows-msvc (rust-lang/cargo#15621)
- fix(fingerprint): explicit reason rather than "stale; unknown reason" (rust-lang/cargo#15617)
- Fix cargo add overwriting symlinked Cargo.toml files (rust-lang/cargo#15281)
- chore(deps): update alpine docker tag to v3.22 (rust-lang/cargo#15616)
r? ghost
Enable Non-determinism of float operations in Miri and change std tests
Links to [#4208](https://github.com/rust-lang/miri/issues/4208) and [#3555](https://github.com/rust-lang/miri/issues/3555) in Miri.
Non-determinism of floating point operations was disabled in rust-lang/rust#137594 because it breaks the tests and doc-tests in core/coretests and std. This PR enables some of them.
This pr includes the following changes:
- Enables the float non-determinism but with a lower relative error of 4ULP instead of 16ULP
- These operations now have a fixed output based on the C23 standard, except the pow operations, this is tracked in [#4286](https://github.com/rust-lang/miri/issues/4286#issue-3010677983)
- Changes tests that made incorrect assumptions about the operations, not to make that assumption anymore (from `assert_eq!` to `assert_approx_eq!`.
- Changed the doctests of the stdlib of these operations to compare against fixed constants instead of `f*::EPSILON`, which now succeed with Miri and `-Zmiri-many-seeds`
- Added a constant `APPROX_DELTA` in `std/tests/floats/f32.rs` which is used for approximation tests, but with a different value when run in Miri. This is to make these tests succeed.
- Added tests in the float tests of Miri to test the C23 behaviour.
Fixes https://github.com/rust-lang/miri/issues/4208
add `Cargo.lock` to CI-rustc allowed list for non-CI env
Changes to dependencies usually require modifying `Cargo.toml`, which would already invalidate the CI-rustc cache if done in non-allowed paths. On non-CI environment, it should be safe to add `Cargo.lock` to the list of allowed paths as there is no real risk aside from a very rare false positive in cases like minor bumps to non-allowed path dependencies without modifying the `Cargo.toml` files.
Fixesrust-lang/rust#141986
Run `calculate_matrix` job on `master` to cache citool builds
As discussed in https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/PR.20ci.20seems.20much.20to.20slow/with/523028903, the current `rust-cache` solution for `citool` doesn't work, because we don't ever write to the cache from `master`, so the cache is empty on PR CI jobs.
This PR runs the `calculate_matrix` job on `master`, with the only motivation to actually prime the cache.
r? `@marcoieni`
Simplify and optimize `VecCache`'s `SlotIndex::from_index`
Simplify and optimize `SlotIndex::from_index`
Break out bucket 0 (containing `idx < 4096`) as an early return, which
simplifies the remainder of the function, and allows optimizing the
`checked_ilog2` since it can no longer return `None`.
This reduces the runtime of `vec_cache::tests::slot_index_exhaustive`
(which calls `SlotIndex::from_index` for every `u32`, twice) from ~15.5s
to ~13.3s.
Separately, simplify the test case as well. (The old and new code passes with
the old and new test case.)
---
Noticed because `slot_index_exhaustive` stood out as taking unusually long compared to other tests, so I started investigating what it was doing.
Don't walk into `Certainty::Yes` goals
Don't walk into `Certainty::Yes` goals in the pending obligation finding code, since they will not have been stalled on an infer var anyways
Remove CollectItemTypesVisitor
I always felt like we were very unnecessarily walking the HIR, let's see if perf agrees
There is lots to ~~improve~~ consolidate further here, as we still have 3 item wfchecks:
* check_item (matching on the hir::ItemKind)
* actually doing trait solver based checks (by using HIR spans)
* lower_item (matching on the hir::ItemKind after loading it again??)
* just ensure_ok-ing a bunch of queries
* check_item_type (matching on DefKind)
* some type based checks, mostly ensure_ok-ing a bunch of queries
fixesrust-lang/rust#121429
Move coroutine_by_move_body_def_id into the big check_crate body owner loop
This avoids starting a parallel loop in sequence and instead runs all the queries for a specific DefId together.
bootstrap: build std sans leaf frame pointers
Sometimes leaf frame-pointers can impact LLVM inlining choices, and that can be a real problem for things like `mul_add`.
Fast path for stalled obligations on self ty
If we see that the `self` type of a goal is an infer var, then don't try to compute the goal at all, since we know that it'll be forced ambiguous.
This is currently only implemented when there are no opaques in the environment. We could extend it to check that the self type is not related to any already defined opaques via subtyping, but I'll leave that as a follow-up.
---
Also stall coerce and subtype predicates if both of their vars are not resolved to concrete types.
---
~~Also, we don't care if the goal is higher-ranked for the sized and copy/clone fast path.~~ pulling this out into another PR.
r? lcnr
Matthias Krüger
bors
Jieyou Xu
Laurențiu Nicola
Laurențiu Nicola
Tshepang Mbambo
The rustc-dev-guide Cronjob Bot
León Orell Valerian Liehr
cyrgani