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.
`-Zremap-cwd-prefix=<to>` was applied inside `parse_remap_path_prefix`, which
resolved `std::env::current_dir()` and pushed `(cwd, to)` onto
`remap_path_prefix`. That option is `[TRACKED_NO_CRATE_HASH]`, so the absolute
working directory entered the incremental command-line-args hash, and building
the same sources from a different directory (e.g. a Bazel sandbox, whose path
contains a per-action counter) purged the whole incremental cache even though the
remapped output is identical.
`--remap-path-prefix` and `-Zremap-cwd-prefix` already have separate options
(`remap_path_prefix` and `remap_cwd_prefix`). Keep each option holding exactly its
own flag, and apply `-Zremap-cwd-prefix` in `file_path_mapping` -- i.e. when
building the (untracked) applied `FilePathMapping` -- rather than when
parsing/tracking options. The absolute cwd then lives only in the runtime mapping,
never in a tracked field.
Output is unchanged (the cwd entry is still appended last). Tracking stays sound:
the cwd's effect is tracked via `remap_cwd_prefix` (the target prefix baked into
output) and `working_dir` (whose `RealFileName` hash includes the real path only
when it was not fully remapped, i.e. exactly when the cwd can leak into output).
The stable `--remap-path-prefix` flag is unchanged in data and in tracking.
A unit test guards against the cwd being merged back into `remap_path_prefix`.
This was necessary when transitioning from JS to wasm exception handling
on Emscripten. Enough time has probably passed that we no longer need to
support JS exception handling on Emscripten. This enables cleaning up a
fair bit of code.
MIR inlining: allow backends to opt-in to inlining intrinsics
This is the same as https://github.com/rust-lang/rust/pull/156398. Github stopped processing updates on that other branch.
r? @oli-obk
Merge several HIR-level queries into one
Now four queries (`local_def_id_to_hir_id`, `opt_hir_owner_nodes`, `opt_ast_lowering_delayed_lints`, `in_scope_traits_map`) were replaced with regular methods which acts like getters.
An `hir_owner` query was added that returns a `ProjectedMaybeOwner` that contains all those fields. `hir_attr_map` remains a separate query as adding attributes to `ProjectedMaybeOwner` led to [perf regressions](https://github.com/rust-lang/rust/pull/155678#issuecomment-4304597871).
There is a similar issue with `in_scopes_trait_map`, but according to the comments from https://github.com/rust-lang/rustc-perf/pull/2436 it is a rare case.
Most of the changes in incremental tests are renames from `opt_hir_owner_nodes` -> `hir_owner`, but there are few cases when new dirty queries were added.
r? @petrochenkov
r? @oli-obk
Add `sync` option to `-Z threads` to force synchronization on one thread
This adds a `sync` option to `-Z threads` to force synchronization while still using one thread. This is useful to measure overhead of synchronization without the noise of additional threads.
Paul Murphy