resolve: Replace `Macros20NormalizedIdent` with `IdentKey`
This is a continuation of https://github.com/rust-lang/rust/pull/150741 and https://github.com/rust-lang/rust/pull/150982 based on the ideas from https://github.com/rust-lang/rust/pull/151491#issuecomment-3784421866.
Before this PR `Macros20NormalizedIdent` was used as a key in various "identifier -> its resolution" maps in `rustc_resolve`.
`Macros20NormalizedIdent` is a newtype around `Ident` in which `SyntaxContext` (packed inside `Span`) is guaranteed to be normalized using `normalize_to_macros_2_0`.
This type is also used in a number of functions looking up identifiers in those maps.
`Macros20NormalizedIdent` still contains span locations, which are useless and ignored during hash map lookups and comparisons due to `Ident`'s special `PartialEq` and `Hash` impls.
This PR replaces `Macros20NormalizedIdent` with a new type called `IdentKey`, which contains only a symbol and a normalized unpacked syntax context. (E.g. `IdentKey` == `Macros20NormalizedIdent` minus span locations.)
So we avoid keeping additional data and doing some syntax context packing/unpacking.
Along with `IdentKey` you can often see `orig_ident_span: Span` being passed around.
This is an unnormalized span of the original `Ident` from which `IdentKey` was obtained.
It is not used in map keys, but it is used in a number of other scenarios:
- diagnostics
- edition checks
- `allow_unstable` checks
This is because `normalize_to_macros_2_0` normalization is lossy and the normalized spans / syntax contexts no longer contain parts of macro backtraces, while the original span contains everything.
Tweak `SlicePartialEq` to allow MIR-inlining the `compare_bytes` call
rust-lang/rust#150265 disabled this because it was a net perf win, but let's see if we can tweak the structure of this to allow more inlining on this side while still not MIR-inlining the loop when it's not just `memcmp` and thus hopefully preserving the perf win.
This should also allow MIR-inlining the length check, which was previously blocked, and thus might allow some obvious non-matches to optimize away as well.
Add FileCheck annotations to simplify_match.rs
Remove `skip-filecheck` and add FileCheck directives to verify that GVN propagates the constant `false` and eliminates the match entirely.
The test now verifies:
- The debug info shows `x` as `const false` (constant propagation)
- No `switchInt` remains (match elimination)
- The function body is just `return` (dead code elimination)
Part of rust-lang/rust#116971.
r? cjgillot
Add `extern crate core` to diagnostic tests
We do this to solve the `failed to resolve: you might be missing crate core` messages that were previously visible in the stderr.
We also split off `subdiagnostic-derive-2` from the main `subdiagnostic-derive`, because the error for this test is now generated post-expansion.
compiler: Rename several types/traits for per-query vtables
- Follow-up to https://github.com/rust-lang/rust/pull/151577
---
This is another round of renaming for some subtle types and traits used by the query system, to hopefully make them easier to understand.
Key renames:
- struct `DynamicQuery` → `QueryVTable` (the actual vtable-like structure)
- struct `DynamicQueries` → `PerQueryVTables` (holds a vtable for each query)
- trait `QueryConfig` → `QueryDispatcher`
- (used by generic functions in `rustc_query_system` to interact with query vtables)
- struct `DynamicConfig` → `SemiDynamicQueryDispatcher`
- (implements `QueryDispatcher` by combining a vtable with some compile-time boolean flags for improved perf)
- trait `QueryConfigRestored` → `UnerasedQueryDispatcher`
- (provides a `QueryDispatcher` while also remembering the query's unerased value type; allows some per-query code to be moved out of macros and into generic functions)
This was trickier than `DepKindVTable`, because there are more types and traits involved, and it's harder to come up with distinctive and useful names for all of them.
There should be no change to compiler behaviour.
r? Kivooeo (or compiler)
Add some clarifications and fixes for fmt syntax
This tries to clarify a few things regarding fmt syntax:
- The comment on `Parser::word` seems to be wrong, as that underscore-prefixed words are just fine. This was changed in https://github.com/rust-lang/rust/pull/66847.
- I struggled to follow the description of the width argument. It referred to a "second argument", but I don't know what second argument it is referring to (which is the first?). Either way, I rewrote the paragraph to try to be a little more explicit, and to use shorter sentences.
- The description of the precision argument wasn't really clear about the distinction of an Nth argument and a named argument. I added a sentence to try to emphasize the difference.
- `IDENTIFIER_OR_KEYWORD` was changed recently in https://github.com/rust-lang/reference/pull/2049 to include bare `_`. But fmt named arguments are not allowed to be a bare `_`.
offload: move (un)register lib into global_ctors
Right now we initialize the openmp/offload runtime before every single offload call, and tear it down directly afterwards.
What we should rather do is initialize it once in the binary startup code, and tear it down at the end of the binary execution. Here I implement these changes.
Together, our generated IR has a lot less usage of globals, which in turn simplifies the refactoring in https://github.com/rust-lang/rust/pull/150683, where I introduce a new variant of our offload intrinsic.
r? oli-obk
Support trait objects in type info reflection
Tracking issue: https://github.com/rust-lang/rust/issues/146922
Adds type_info support for trait object types by introducing a DynTrait variant
~~I can't seem to get it to work correctly with `dyn for<'a> Foo<'a>`, though it works fine for normal `dyn Foo` trait objects~~
r? @oli-obk
Remove `skip-filecheck` and add FileCheck directives to verify that GVN
propagates the constant `false` and eliminates the match entirely.
The test now verifies:
- The debug info shows `x` as `const false` (constant propagation)
- No `switchInt` remains (match elimination)
- The function body is just `return` (dead code elimination)
Don't try to evaluate const blocks during constant promotion
As of https://github.com/rust-lang/rust/pull/138499, trying to evaluate a const block in anything depended on by borrow-checking will result in a query cycle. Since that could happen in constant promotion, this PR adds a check for const blocks there to stop them from being evaluated.
Admittedly, this is a hack. See https://github.com/rust-lang/rust/issues/124328 for discussion of a more principled fix: removing cases like this from constant promotion altogether. To simplify the conditions under which promotion can occur, we probably shouldn't be implicitly promoting division or array indexing at all if possible. That would likely require a FCW and migration period, so I figure we may as well patch up the cycle now and simplify later.
Fixesrust-lang/rust#150464
I'll also lang-nominate this for visibility. I'm not sure there's much to discuss about this PR specifically, but it does represent a change in semantics. In Rust 1.87, the code below compiled. In Rust 1.88, it became a query cycle error. After this PR, it fails to borrow-check because the temporaries can no longer be promoted.
```rust
let (x, y, z);
// We only promote array indexing if the index is known to be in-bounds.
x = &([0][const { 0 }] & 0);
// We only promote integer division if the divisor is known not to be zero.
y = &(1 / const { 1 });
// Furthermore, if the divisor is `-1`, we only promote if the dividend is
// known not to be `int::MIN`.
z = &(const { 1 } / -1);
// The borrowed temporaries can't be promoted, so they were dropped at the ends
// of their respective statements.
(x, y, z);
```
std: move time implementations to `sys`
This is probably the most complex step of rust-lang/rust#117276 so far. Unfortunately, quite some of the internal time logic defined in the PAL is also used in other places like the filesystem code, so this isn't just a series of simple moves. I've left all that logic inside the PAL and only moved the actual `SystemTime`/`Instant` implementations.
While there are no functional changes, this PR also contains some slight code cleanups on Windows and Hermit, these are explained in the relevant commits.
For additional details see the individual commits, I've tried to make the messages as helpful as possible about what's going on.
compiletest: Add `CompilerKind` to distinguish between rustc and rustdoc
This PR slightly improves `TestCx::make_compile_args` by using `CompilerKind` to explicitly distinguish between rustc and rustdoc.
The resulting code could still use more attention, but I think this is a good incremental improvement.
There *should* (hopefully) be no change to overall compiletest behaviour.
Last on the list: Hermit. Since I anticipate that Hermit will share the UNIX
implementation in the future, I've left `Timespec` in the PAL to maintain a
similar structure. Also, I noticed that some public `Instant` methods were
redefined on the internal `Instant`. But the networking code can just use the
public `Instant`, so I've removed them.
WASI and TEEOS share the UNIX implementation. Since `Timespec` lives in the
PAL, this means that the `#[path]` imports of `unix/time.rs` still remain for
these two, unfortunately. Maybe we'll solve that in the future by always
including the UNIX PAL for these remotely UNIXy platforms. But that's a story
for another time...
Now for UNIX: `Timespec` is also used for things like futex or `Condvar`
timeouts, so it stays in the PAL along with some related definitions.
Everything else is `SystemTime`- and `Instant`-specific, and is thus moved to
`sys::time`.
Windows has a similar problem as UEFI: some internals are also used for
implementing other things. Thus I've left everything except for the actual
`Instant` and `SystemTime` implementations inside the PAL.
I've also taken the liberty of improving the code clarity a bit: there were a
number of manual `SystemTime` conversions (including one that masked an `i64`
to 32-bits before casting to `u32`, yikes) that now just call `from_intervals`.
Also, defining a `PerformanceCounterInstant` just to convert it to a regular
`Instant` immediately doesn't really make sense to me. I've thus changed the
`perf_counter` module to contain only free functions that wrap system
functionality. The actual conversion now happens in `Instant::now`.
Next up: UEFI. Unfortunately the time conversion internals are also required by
the filesystem code, so I've left them in the PAL. The `Instant` internals
however are only used for the `Instant` implementation, so I've moved them to
`sys` (for now).
On SOLID, the conversion functions are also used to implement helpers for
timeout conversion, so these stay in the PAL. The `Instant` (µITRON) and
`SystemTime` (SOLID-specific) implementations are merged into one. While it was
nice to have the µITRON parts in a separate module, there really isn't a need
for this currently, as there is no other µITRON target. Let's not worry about
this until such a target gets added...
Note that I've extracted the `get_tim` call from `Instant` into a wrapper
function in the PAL to avoid the need to make the inner `Instant` field public
for use in the PAL.
Now that the `unsupported` module exists, we can use it for VEX. VEX actually
supports `Instant` though, so the implementation-select needs to combine that
with the `unsupported` module.
Let's start with the easy ones:
* Motor just reexports its platform library
* The SGX code is just a trivial move
* Trusty, WASM and ZKVM are unsupported, this is very trivial. And we can get
rid of some `#[path = ...]`s, yay!
150265 disabled this because it was a net perf win, but let's see if we can tweak the structure of this to allow more inlining on this side while still not MIR-inlining the loop when it's not just `memcmp`.
This should also allow MIR-inlining the length check, which was previously blocked.
