Rollup of 3 pull requests
Successful merges:
- rust-lang/rust#152357 (std: Don't panic when removing a nonexistent UEFI var)
- rust-lang/rust#152180 (Port `rustc_reservation_impl` to the new attribute parser)
- rust-lang/rust#152276 (Add message format checking)
Add message format checking
Checks the indentation of diagnostic messages, it checks that everything is at least as indented as the attribute that contains it
r? @jdonszelmann (Anyone else, also feel free to review, just assigning to Jana because she's been reviewing the other PRs)
std: Don't panic when removing a nonexistent UEFI var
`std::env::remove_var` does not say that deleting a nonexistent variable is an error (and at least on Linux, it indeed does not cause an error).
The UEFI Shell Protocol spec also doesn't say it's an error, but the edk2 implementation delegates to the UEFI runtime `SetVariable` function, which returns `EFI_NOT_FOUND` when trying to delete a nonexistent variable.
Change the UEFI implementation to check for a `NotFound` error and treat it as success.
CC @Ayush1325
Remove `QueryDispatcher`
`QueryDispatcher` is a trait that existed purely because `rustc_query_system` had code that didn't have access to `TyCtxt`. That is no longer the case, so the trait can be removed.
r? @Zalathar
It existed only to bridge the divide between `rustc_query_system` and
`rustc_query_impl`. But enough pieces have been moved from the former to
the latter that the trait is no longer needed. Less indirection and
abstraction makes the code easier to understand.
It takes an `is_anon` argument, but it's now generic over `QueryFlags`,
which contains the same `is_anon` field. So the argument is no longer
necessary.
Port `rustc_insignificant_dtor`
r? @JonathanBrouwer
Second commit removes it from an impl in std. I looked, and I really think it had no effect in the past. We only look for this attr on ADTs...
Implement MVP for opaque generic const arguments
This is meant to be the interim successor to generic const expressions.
Essentially, const item RHS's will be allowed to do arbitrary const
operations using generics. The limitation is that these const items will
be treated opaquely, like ADTs in nominal typing, such that uses of them
will only be equal if the same const item is referenced. In other words,
two const items with the exact same RHS will not be considered equal.
I also added some logic to check feature gates that depend on others
being enabled (like oGCA depending on mGCA).
### Coherence
During coherence, OGCA consts should be normalized ambiguously because
they are opaque but eventually resolved to a real value. We don't want
two OGCAs that have the same value to be treated as distinct for
coherence purposes. (Just like opaque types.)
This actually doesn't work yet because there are pre-existing
fundamental issues with equate relations involving consts that need to
be normalized. The problem is that we normalize only one layer of the
const item and don't actually process the resulting anon const. Normally
the created inference variable should be handled, which in this case
would cause us to hit the anon const, but that's not happening.
Specifically, `visit_const` on `Generalizer` should be updated to be
similar to `visit_ty`.
r? @BoxyUwU
Streamline `rustc_span::HashStableContext`.
Currently this trait has five methods. But it only really needs three.
For example, currently stable hashing of spans is implemented in `rustc_span`, except a couple of sub-operations are delegated to `rustc_query_system`: `def_span` and `span_data_to_lines_and_cols`. These two delegated sub-operations can be reduced to a single delegated operation that does the full hash computation.
Likewise, `assert_default_hashing_controls` depends on two delegated sub-operations, `hashing_controls` and
`unstable_opts_incremental_ignore_spans`, and can be simplified.
I find the resulting code simpler and clearer -- when necessary, we do a whole operation in `rustc_query_system` instead of doing it partly in `rustc_span` and partly in `rustc_query_system`.
r? @cjgillot
It's always `SemiDynamicQueryDispatcher`, so we can just use that type
directly. (This requires adding some explicit generic params to
`QueryDispatcherUnerased`.) Less indirection makes the code clearer, and
this is a prerequisite for the next commit, which is a much bigger
simplification.
Query keys must be stably hashable. Currently this requirement is
expressed as a where-clause on `impl QueryDispatcher for
SemiDynamicQueryDispatcher` and a where-clause on
`create_deferred_query_stack_frame`.
This commit removes those where-clause bounds and adds a single bound to
`QueryCache::Key`, which already has some other bounds. I.e. it
consolidates the bounds. It also gives them a name (`QueryCacheKey`) to
avoid repeating them. There is also a related `Key` trait in
`rustc_middle`; it should probably be merged with `QueryCacheKey` in the
future, but not today.
This cleanup helps with the next two commits, which do bigger
rearrangements, and where the where-clauses caused me some difficulties.
Stop having two different alignment constants
Now that there's a `<T as SizedTypeProperties>::ALIGNMENT` constant, `Alignment::of` can use that instead of an inline constant, like how `Layout::new` uses the constant from `SizedTypeProperties`.
Reword the caveats on `array::map`
Thanks to #107634 and some improvements in LLVM (particularly [`dead_on_unwind`](https://llvm.org/docs/LangRef.html#parameter-attributes)), the method actually optimizes reasonably well now.
So focus the discussion on the fundamental ordering differences where the optimizer might never be able to fix it because of the different behaviour, and keep encouraging `Iterator::map` where an array wasn't actually ever needed.
bootstrap: always propagate `CARGO_TARGET_{host}_LINKER`
We were already setting `CARGO_TARGET_{target}_LINKER` when there is a
setting in `bootstrap.toml`, and when the host and target are the same,
this is also used for build scripts and proc-macros.
However, the host value wasn't set when building for any other target,
and Cargo would see that as a fingerprint change for those build
artifacts, rebuilding them.
If we always set the `CARGO_TARGET_{host}_LINKER`, then those build
scripts will keep a consistent Cargo fingerprint, so they'll remain
cached no matter how we're alternating targets.
diagnostics: fix ICE in closure signature mismatch
Fixesrust-lang/rust#152331
Fixes an ICE where `AdjustSignatureBorrow` caused a panic because it attempted to set the `len` argument which was already defined by the parent diagnostic.
Both variants used `len` as argument name, but can both be present in a diagnostic. They now use different names for the argument.
Cleanup offload datatransfer
There are 3 steps to run code on a GPU: Copy data from the host to the device, launch the kernel, and move it back.
At the moment, we have a single variable describing the memory handling to do in each step, but that makes it hard for LLVM's opt pass to understand what's going on. We therefore split it into three variables, each only including the bits relevant for the corresponding stage.
cc @jdoerfert @kevinsala
r? compiler
Fix a few diagnostics
When working on the inline diagnostics conversion (https://github.com/rust-lang/rust/issues/151366), I noticed that my script sometimes took the wrong message.
Because it didn't happen very often, I just fixed it manually when a uitest fails.
However I got paranoid that the script changed messages that were not covered by uitests, so I checked for all messages in the previous `messages.ftl` files, whether they occured at least once in the codebase. I found 3 messages that indeed were wrongly replaced by my script, fixed them, and added uitests to make sure this doesn't happen again :)
r? @jdonszelmann (Anyone else, also feel free to review, just assigning to Jana because she's been reviewing the other PRs)
Replace some `feature(core_intrinsics)` with stable hints
I noticed that some compiler crates use `feature(core_intrinsics)` for optimization hints, when they could potentially be using stable `std::hint` functions instead.
This PR replaces the occurrences in `rustc_arena` and `rustc_data_structures`.
Fix `SourceFile::normalized_byte_pos`
This method was broken by 258ace6, which changed `self.normalized_pos` to use relative offsets however this method continued to compare against an absolute offset.
Also adds a regression test for the issue that this method was originally introduced to fix.
Closesrust-lang/rust#149568
Fixes regression of rust-lang/rust#110885
r? cjgillot (as author of the breaking commit)
This is meant to be the interim successor to generic const expressions.
Essentially, const item RHS's will be allowed to do arbitrary const
operations using generics. The limitation is that these const items will
be treated opaquely, like ADTs in nominal typing, such that uses of them
will only be equal if the same const item is referenced. In other words,
two const items with the exact same RHS will not be considered equal.
I also added some logic to check feature gates that depend on others
being enabled (like oGCA depending on mGCA).
= Coherence =
During coherence, OGCA consts should be normalized ambiguously because
they are opaque but eventually resolved to a real value. We don't want
two OGCAs that have the same value to be treated as distinct for
coherence purposes. (Just like opaque types.)
This actually doesn't work yet because there are pre-existing
fundamental issues with equate relations involving consts that need to
be normalized. The problem is that we normalize only one layer of the
const item and don't actually process the resulting anon const. Normally
the created inference variable should be handled, which in this case
would cause us to hit the anon const, but that's not happening.
Specifically, `visit_const` on `Generalizer` should be updated to be
similar to `visit_ty`.
`std::env::remove_var` does not say that deleting a nonexistent variable
is an error (and at least on Linux, it indeed does not cause an
error).
The UEFI Shell Protocol spec also doesn't say it's an error, but the
edk2 implementation delegates to the UEFI runtime `SetVariable`
function, which returns `EFI_NOT_FOUND` when trying to delete a
nonexistent variable.
Change the UEFI implementation to check for a `NotFound` error and treat
it as success.
Start cutting down `rustc_query_system`
The query system is implemented in `rustc_query_system`, `rustc_middle`, and `rustc_query_impl`. `rustc_query_system` is hamstrung by not having access to `TyCtxt`, and there seems to be consensus to eliminate it. It's contents can be moved into the other two crates. Moving as much stuff as possible to `rustc_query_impl` is preferred, because `rustc_middle` is already so big.
This PR starts this process. It moves one small function to `rustc_middle` and a good chunk of code to `rustc_query_impl`.
Once `rustc_query_system` is gone (or at least shrunk down a lot more) some of the traits like `DepContext`, `QueryContext`, and `QueryDispatcher` will be removable.
r? @Zalathar
