Initialize LLVM time trace profiler on each code generation thread
In https://reviews.llvm.org/D71059 LLVM 11, the time trace profiler was
extended to support multiple threads.
`timeTraceProfilerInitialize` creates a thread local profiler instance.
When a thread finishes `timeTraceProfilerFinishThread` moves a thread
local instance into a global collection of instances. Finally when all
codegen work is complete `timeTraceProfilerWrite` writes data from the
current thread local instance and the instances in global collection
of instances.
Previously, the profiler was intialized on a single thread only. Since
this thread performs no code generation on its own, the resulting
profile was empty.
Update LLVM codegen to initialize & finish time trace profiler on each
code generation thread.
cc `@tmandry`
r? `@wesleywiser`
Implementation of GATs outlives lint
See #87479 for background. Closes#87479
The basic premise of this lint/error is to require the user to write where clauses on a GAT when those bounds can be implied or proven from any function on the trait returning that GAT.
## Intuitive Explanation (Attempt) ##
Let's take this trait definition as an example:
```rust
trait Iterable {
type Item<'x>;
fn iter<'a>(&'a self) -> Self::Item<'a>;
}
```
Let's focus on the `iter` function. The first thing to realize is that we know that `Self: 'a` because of `&'a self`. If an impl wants `Self::Item` to contain any data with references, then those references must be derived from `&'a self`. Thus, they must live only as long as `'a`. Furthermore, because of the `Self: 'a` implied bound, they must live only as long as `Self`. Since it's `'a` is used in place of `'x`, it is reasonable to assume that any value of `Self::Item<'x>`, and thus `'x`, will only be able to live as long as `Self`. Therefore, we require this bound on `Item` in the trait.
As another example:
```rust
trait Deserializer<T> {
type Out<'x>;
fn deserialize<'a>(&self, input: &'a T) -> Self::Out<'a>;
}
```
The intuition is similar here, except rather than a `Self: 'a` implied bound, we have a `T: 'a` implied bound. Thus, the data on `Self::Out<'a>` is derived from `&'a T`, and thus it is reasonable to expect that the lifetime `'x` will always be less than `T`.
## Implementation Algorithm ##
* Given a GAT `<P0 as Trait<P1..Pi>>::G<Pi...Pn>` declared as `trait T<A1..Ai> for A0 { type G<Ai...An>; }` used in return type of one associated function `F`
* Given env `E` (including implied bounds) for `F`
* For each lifetime parameter `'a` in `P0...Pn`:
* For each other type parameter `Pi != 'a` in `P0...Pn`: // FIXME: this include of lifetime parameters too
* If `E => (P: 'a)`:
* Require where clause `Ai: 'a`
## Follow-up questions ##
* What should we do when we don't pass params exactly?
For this example:
```rust
trait Des {
type Out<'x, D>;
fn des<'z, T>(&self, data: &'z Wrap<T>) -> Self::Out<'z, Wrap<T>>;
}
```
Should we be requiring a `D: 'x` clause? We pass `Wrap<T>` as `D` and `'z` as `'x`, and should be able to prove that `Wrap<T>: 'z`.
r? `@nikomatsakis`
`Candidate` enum has only a single `Ref` variant. Refactor it into a
struct and reduce overall indentation of the code by two levels.
No functional changes.
Properly register text_direction_codepoint_in_comment lint.
This makes it known to the compiler so it can be configured like with `#![allow(text_direction_codepoint_in_comment)]`.
Fixes#90614.
In https://reviews.llvm.org/D71059 LLVM 11, the time trace profiler was
extended to support multiple threads.
`timeTraceProfilerInitialize` creates a thread local profiler instance.
When a thread finishes `timeTraceProfilerFinishThread` moves a thread
local instance into a global collection of instances. Finally when all
codegen work is complete `timeTraceProfilerWrite` writes data from the
current thread local instance and the instances in global collection
of instances.
Previously, the profiler was intialized on a single thread only. Since
this thread performs no code generation on its own, the resulting
profile was empty.
Update LLVM codegen to initialize & finish time trace profiler on each
code generation thread.
Demote metadata load warning to "info".
There is a warn log message for whenever the crate loader fails to load metadata from a candidate file. I think this warning is too aggressive, as there are several situations where metadata information might not be found in a candidate file, which is normal. Also, this warning is somewhat confusing, and non-actionable in most cases for a user (most users will not know what it means).
If the crate loader ultimately does not find a valid crate, then an error will be reported (and hopefully #88368 will improve that error message).
If a rustc developer wants to debug a loader problem, they can still use `RUSTC_LOG=rustc_metadata=debug` and get the details.
There is more discussion of this particular warning at https://github.com/rust-lang/rust/issues/89795#issuecomment-940798190.
Fixes#90525
Update aarch64 `target_feature` list for LLVM 12.
Many of these feature are now available on all valid LLVM versions.
I've also added a few new ones to the list.
r? `@Amanieu`
update rustc_ast crate descriptions in documentation
I noticed this the other day and figured I'd suggest a refresh. It seems like a relic from the days of `libsyntax` that got missed as things were split out into separate crates, since the current documentation text references elements that were moved into their own respective crates (e.g. `rustc_parse`)
Add beginner friendly lifetime elision hint to E0623
Address #90170
Suggest adding a new lifetime parameter when two elided lifetimes should match up but don't.
Example:
```
error[E0623]: lifetime mismatch
--> $DIR/issue-90170-elision-mismatch.rs:2:35
|
LL | fn foo(slice_a: &mut [u8], slice_b: &mut [u8]) {
| --------- --------- these two types are declared with different lifetimes...
LL | core::mem::swap(&mut slice_a, &mut slice_b);
| ^^^^^^^^^^^^ ...but data from `slice_b` flows into `slice_a` here
|
= note: each elided lifetime in input position becomes a distinct lifetime
help: explicitly declare a lifetime and assign it to both
|
LL | fn foo<'a>(slice_a: &'a mut [u8], slice_b: &'a mut [u8]) {
| ++++ ++ ++
```
for
```rust
fn foo(slice_a: &mut [u8], slice_b: &mut [u8]) {
core::mem::swap(&mut slice_a, &mut slice_b);
}
```
Suggest adding a new lifetime parameter when two elided lifetimes should match up but don't
Issue #90170
This also changes the tests introduced by the previous commits because of another rustc issue (#90258)
The exact set of permissions granted when forming a raw reference is
currently undecided https://github.com/rust-lang/rust/issues/56604.
To avoid presupposing any particular outcome, adjust the const
qualification to be compatible with decision where raw reference
constructed from `addr_of!` grants mutable access.
This is just replicating the previous algorithm, but taking advantage of the
bitset structures to optimize into tighter and better optimized loops.
Particularly advantageous on enormous MIR blocks, which are relatively rare in
practice.
Use apple-a14 as target CPU for aarch64-apple-darwin
After updating the minimum required LLVM version to 12 (#90175) we can use `apple-a14` as target CPU, because that CPU is similar in features to the Apple M1 (see [LLVM 13 source](b8016b626e/llvm/lib/Target/AArch64/AArch64.td (L1127))). Once the minimum required LLVM version is updated to 13 we can use `apple-m1` here.
