Move `Limit` out of `rustc_hir`
It feels rather out of place in `rustc_hir`, so this PR moves it to `rustc_data_structures`. Part of hopefully moving attributes from `rustc_hir` to their own crate.
~~This also lets `rustc_type_ir` use it~~ actually rustc_type_ir needs to compile on stable and `rustc_data_structures` uses like 30 features 😢
rustc: Avoid passing jobserver proxy around the compiler
It is used once, when marking a `rustc_thread_pool` worker thread as blocked. `rustc_thread_pool` already has access to the jobserver proxy, so we can move its use from outside of `mark_blocked` to inside of it.
(The modified part of `rustc_thread_pool` is a rustc-specific extension, not an original rayon-core API.)
This is a simpler cleanup subset of https://github.com/rust-lang/rust/pull/155997.
r? @nnethercote
Fix ICE in `write_interface` when the interface file can't be written
Fixesrust-lang/rust#143981.
`write_interface` opened the `sdylib` interface file with `fs::File::create_buffered(...).unwrap()`, so any failure to create it (like `-o` into a non-existent or unwritable directory) will ICE instead of reporting a normal error. Emit `FailedWritingFile` instead, matching the rlink and dep-graph write paths.
Also drop a stray trailing `"` from the `FailedWritingFile` in `diagnostic.rs` and `error.rs`.
It is used once, when marking a `rustc_thread_pool` worker thread as blocked.
`rustc_thread_pool` already has access to the jobserver proxy, so we can move its use from outside of `mark_blocked` to inside of it.
Add -Zautodiff_post_passes flag to limit which llvm passes to run after enzyme to make autodiff tests more robust
* Add -Zautodiff_post_passes flag to limit which llvm passes to run after enzyme to make autodiff tests more robust
* Change some llvm ir check in codegen_llvm/autodiff tests
r? @ZuseZ4
Sometimes it is necessary to group patchable function entrypoint
records in distinct linker sections. This is the case for some bpf
functions within the linux kernel which shouldn't be visible to
ftrace.
Extend `-Zpatchable-function-entry` to accept an argument of the form
`prefix_nops,total_nops,record_section`, which places all entry
record into a user specified section.
Likewise, extend the `patchable_function_entry` attribute to accept an
optional `section="name"` option to place a function into a specific
section.
This is made possible by llvm attribute `patchable-function-entry-section`
added in llvm 21.
Add -Zinstrument-mcount=fentry to -Zinstrument-mcount
fentry is essentially a simpler version of mcount where the counting function is called before any other function prologue actions happen.
fentry is still used by the linux x86-64 kernel. It's unclear if or when patchable-function-entry will replace it. It is also used by clang for some x86-64 mingw toolchains.
This is only supported on some x86, x86-64, and s390x targets.
It's called in two cases: pre-expansion lists, and early lints. The
appropriate builtin pass is specified at the call site but the
appropriate other passes are chosen within, which is inconsistent.
This commit changes it so everything is chosen within, based on the
boolean `pre_expansion_lint` parameter. `check_ast_node_inner` is split
into `run_passes` and `run_pass`; the extra function is needed because
the genericness of `builtin_lints` is pushed down one level below
`check_ast_node`.
Remove `has_delayed_lints` optimization
Keeping track of `has_delayed_lints` doesn't seem to have a perf effect anymore so let's not make the code more complicated than needed. These flags were previously used so we don't have to iterate over all hir owners, but iterating over all hir owners seems fast enough
cc @jdonszelmann
This reduces the size of PATH on windows during macro expansion to avoid
hitting windows limits. With the new Cargo build-dir layout this becomes
more important as Cargo now passes more `-L` args which end up bloating
PATH.
It only has two impls, both of which are tuples, which is ugly. An enum
is much simpler and clearer.
Also, `EarlyContextAndPass` doesn't need to be public.
fentry is essentially a simpler version of mcount where the
counting function is called before any other function prologue
actions happen.
fentry is still used by the linux x86-64 kernel. It's unclear if
or when patchable-function-entry will replace it. It is also used
by clang for some x86-64 mingw toolchains.
This is only supported on some x86, x86-64, and s390x targets.
Staticlib rename internal symbols
Follow-up to rust-lang/rust#155338.
`-Zstaticlib-rename-internal-symbols` appends a crate-specific suffix (`_rs{StableCrateId}`) to non-exported symbols, resolving duplicate symbol conflicts when linking multiple Rust staticlibs into the same binary.
The implementation collects all defined `GLOBAL/WEAK` symbol names not in the exported set across all .o files, then renames them by extending the strtab and patching symbol name offsets. When combined with `-Zstaticlib-hide-internal-symbols`, the renamed symbols also receive `STV_HIDDEN` visibility.
Supported on ELF targets (Linux, BSD, etc.) and Apple targets (macOS, iOS, etc.). On unsupported targets (Windows), a warning is emitted and the flag has no effect.
r?@bjorn3 @petrochenkov
Don't track cwd for `-Zremap-cwd-prefix` in incremental compilation
## Summary
`-Zremap-cwd-prefix=<to>` defeats incremental compilation whenever the build directory changes (Bazel sandboxes, CI checkouts with per-build paths), even though the remapped output is identical:
```
[incremental] completely ignoring cache because of differing commandline arguments
```
This fixes the cwd half of rust-lang/rust#132132.
### Root cause
`-Zremap-cwd-prefix` and `--remap-path-prefix` have two separate options (`remap_cwd_prefix` and `remap_path_prefix`), but `parse_remap_path_prefix` *merges* them: it resolves `std::env::current_dir()` and pushes `(cwd, to)` onto `remap_path_prefix`, which is `[TRACKED_NO_CRATE_HASH]`. The **absolute** cwd thus enters `dep_tracking_hash(false)` (compared in `rustc_incremental::persist::load`), so the same build from a different directory purges the whole incremental session.
### Fix: apply the cwd prefix where the mapping is built, not where options are tracked
Keep each option holding exactly its own flag, and apply `-Zremap-cwd-prefix` in `file_path_mapping` — i.e. while building the (untracked) applied `FilePathMapping` — instead of in `parse_remap_path_prefix`. The absolute cwd then lives only in the runtime mapping and never in a tracked option.
**Behaviour-preserving for output:** the applied mapping is identical (the cwd entry is still appended last, so it keeps taking precedence over `--remap-path-prefix` as documented), and all emitted paths (debuginfo, diagnostics, metadata) are unchanged.
**Sound for tracking:** the cwd's effect is still tracked, by the two options that *should* carry it —
* `remap_cwd_prefix` (`[TRACKED]`) — the target prefix baked into output;
* `working_dir` (`[TRACKED]`) — and `RealFileName`'s hash already includes the real local path **only** when the path was not fully remapped (`was_fully_remapped()` = `scopes.is_all()`):
```rust
if !self.was_fully_remapped() { self.local.hash(state); }
self.maybe_remapped.hash(state);
```
So under a restrictive `-Zremap-path-scope` (where the cwd can still leak into output) the real cwd stays tracked via `working_dir`; under full remapping (where it cannot leak) it is correctly ignored. Dropping the cwd from `remap_path_prefix`'s hash is therefore sound in **every** scope.
The **stable** `--remap-path-prefix` flag is entirely unchanged in data and in tracking. No SVH/crate-hash change (`remap_path_prefix` is `TRACKED_NO_CRATE_HASH`); no new types and no special-case hashing.
### Notes
* A unit test (`tests/ui`-style, in `rustc_interface`) guards against the cwd being merged back into the tracked `remap_path_prefix`, while asserting it is still applied via `file_path_mapping`.
* The unstable book entry for `-Zremap-cwd-prefix` is updated to document the incremental-cache behaviour across build directories.
* A `tests/run-make` end-to-end test (build the same sources from two directories sharing one `-Cincremental` dir, asserting cache reuse) would be a good follow-up; happy to add it here if preferred.
### Relation to stabilization (tracking issue rust-lang/rust#89434)
This is a behaviour fix to an unstable flag and does not depend on or block stabilization. It is, however, mildly relevant to one of the open questions in the tracking issue (rust-lang/rust#89434) — *"Will this always be defined to be the same as `--remap-path-prefix=$(pwd)=VALUE`?"*. After this PR the two are **no longer** equivalent for incremental compilation: a literal `--remap-path-prefix=$(pwd)=.` still bakes the absolute cwd into the tracked hash, whereas `-Zremap-cwd-prefix=.` no longer does. Worth keeping in mind whenever that question is revisited (e.g. alongside RFC 3127).
r? compiler
Emit error for unused target expression in glob and list delegations
This PR emits error if unuse target expression is specified for glob delegation. Second part of rust-lang/rust#156798.
Part of rust-lang/rust#118212.
r? @petrochenkov
This is an UnordMap internally. Iteration order for the work product map
should not matter aside from the place it is serialized where sorting by
WorkProductId is sufficient.
delegation: split resolution and lowering
This PR splits delegation's AST -> HIR lowering and its resolution. Now we resolve all delegations and then lower them. This should have benefits:
- ~For rust-lang/rust#156798, where it will be convenient to insert diagnostics about specifying target expressions for glob reuses of only static functions (the `delegations_resolutions` map will contain information whether to lower or delete target expression)~
- For rust-lang/rust#155337 and delegations to inherent methods resolution, as from what I tested up until now we should resolve them in iterative manner before AST -> HIR lowering.
Part of rust-lang/rust#118212.
r? @petrochenkov
Rollup of 3 pull requests
Successful merges:
- rust-lang/rust#156210 (Emit retags in codegen to support BorrowSanitizer (part 2))
- rust-lang/rust#157317 (Fix ICE when wrong intra-doc link on type alias)
- rust-lang/rust#157391 (Reorganize `tests/ui/issues` [4/N])
Emit retags in codegen to support BorrowSanitizer (part 2)
Tracking issue: rust-lang/rust#154760
[Zulip Thread](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Staging.20for.20emitting.20retags.20in.20codegen/with/593004012)
This is one of several PRs that will add experimental support for emitting retags as function calls in codegen. Each PR will be a minimal, improved slice of the changes in rust-lang/rust#155965.
This PR adds a new unstable flag `-Zcodegen-emit-retag`, which will enable experimental retag calls in generated code. This flag is a nop for now, but the relevant methods have been added to codegen_ssa, and they are called wherever retags are necessary. Subsequent PRs will complete this implementation.
This does not depend on rust-lang/rust#156208.
r? @RalfJung
Introduce `TypingMode::Codegen` to avoid layout cycles on coroutines
Computing layout of coroutines depends on their `optimized_mir`. At the same time, MIR opts can require using layouts to work. For instance to evaluate constants. This leads to cycles and clumsy workarounds.
This PR creates a new typing mode for layout computations:
- when a coroutine's layout is requested with `TypingMode::PostAnalysis` or earlier, return `LayourError::TooGeneric`;
- when a coroutine's layout is requested with `TypingMode::Codegen`, actually compute it.
`TypingMode::Codegen` is meant be be used by codegen code, and analyses that require coroutine layout, like transmute check and coroutine recursion check.
With this PR, we can remove all `is_coroutine` checks from `rustc_mir_transform` and unlock simplifying coroutine MIR.
Perf is not terrific. This PR causes recomputation of a few queries, and I had to insert workarounds.
Jonathan Brouwer