Add support for LLVM coverage mapping format versions 5 and 6
This PR cherry-pick's Swatinem's initial commit in unsubmitted PR #90047.
My additional commit augments Swatinem's great starting point, but adds full support for LLVM
Coverage Mapping Format version 6, conditionally, if compiling with LLVM 13.
Version 6 requires adding the compilation directory when file paths are
relative, and since Rustc coverage maps use relative paths, we should
add the expected compilation directory entry.
Note, however, that with the compilation directory, coverage reports
from `llvm-cov show` can now report file names (when the report includes
more than one file) with the full absolute path to the file.
This would be a problem for test results, but the workaround (for the
rust coverage tests) is to include an additional `llvm-cov show`
parameter: `--compilation-dir=.`
Take a LocalDefId in expect_*item.
Items and item-likes are always HIR owners.
When trying to find such nodes, there is no ambiguity, the `LocalDefId` and the `HirId::owner` always match.
In such cases, `local_def_id_to_hir_id` does not carry any meaningful information, so we can just skip calling it altogether.
Print associated types on opaque `impl Trait` types
This PR generalizes #91021, printing associated types for all opaque `impl Trait` types instead of just special-casing for future.
before:
```
error[E0271]: type mismatch resolving `<impl Iterator as Iterator>::Item == u32`
```
after:
```
error[E0271]: type mismatch resolving `<impl Iterator<Item = usize> as Iterator>::Item == u32`
```
---
Questions:
1. I'm kinda lost in binders hell with this one. Is all of the `rebind`ing necessary?
2. Is there a map collection type that will give me a stable iteration order? Doesn't seem like TraitRef is Ord, so I can't just sort later..
3. I removed the logic that suppresses printing generator projection types. It creates outputs like this [gist](https://gist.github.com/compiler-errors/d6f12fb30079feb1ad1d5f1ab39a3a8d). Should I put that back?
4. I also added spaces between traits, `impl A+B` -> `impl A + B`. I quite like this change, but is there a good reason to keep it like that?
r? ````@estebank````
Suggestion to wrap inner types using 'allocator_api' in tuple
This PR provides a suggestion to wrap the inner types in tuple when being along with 'allocator_api'.
Closes https://github.com/rust-lang/rust/issues/83250
```rust
fn main() {
let _vec: Vec<u8, _> = vec![]; //~ ERROR use of unstable library feature 'allocator_api'
}
```
```diff
error[E0658]: use of unstable library feature 'allocator_api'
--> $DIR/suggest-vec-allocator-api.rs:2:23
|
LL | let _vec: Vec<u8, _> = vec![];
- | ^
+ | ----^
+ | |
+ | help: consider wrapping the inner types in tuple: `(u8, _)`
|
= note: see issue #32838 <https://github.com/rust-lang/rust/issues/32838> for more information
= help: add `#![feature(allocator_api)]` to the crate attributes to enable
```
Elaborate `Future::Output` when printing opaque `impl Future` type
I would love to see the `Output =` type when printing type errors involving opaque `impl Future`.
[Test code](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=a800b481edd31575fbcaf5771a9c3678)
Before (cut relevant part of output):
```
note: while checking the return type of the `async fn`
--> /home/michael/test.rs:5:19
|
5 | async fn bar() -> usize {
| ^^^^^ checked the `Output` of this `async fn`, found opaque type
= note: expected type `usize`
found opaque type `impl Future`
```
After:
```
note: while checking the return type of the `async fn`
--> /home/michael/test.rs:5:19
|
5 | async fn bar() -> usize {
| ^^^^^ checked the `Output` of this `async fn`, found opaque type
= note: expected type `usize`
found opaque type `impl Future<Output = usize>`
```
Note the "found opaque type `impl Future<Output = usize>`" in the new output.
----
Questions:
1. We skip printing the output type when it's a projection, since I have been seeing some types like `impl Future<Output = <[static generator@/home/michael/test.rs:2:11: 2:21] as Generator<ResumeTy>>::Return>` which are not particularly helpful and leak implementation detail.
* Am I able to normalize this type within `rustc_middle::ty::print::pretty`? Alternatively, can we normalize it when creating the diagnostic? Otherwise, I'm fine with skipping it and falling back to the old output.
* Should I suppress any other types? I didn't encounter anything other than this generator projection type.
2. Not sure what the formatting of this should be. Do I include spaces in `Output = `?
fix CTFE/Miri simd_insert/extract on array-style repr(simd) types
The changed test would previously fail since `place_index` would just return the only field of `f32x4`, i.e., the array -- rather than *indexing into* the array which is what we have to do.
The new helper methods will also be needed for https://github.com/rust-lang/miri/issues/1912.
r? ``````@oli-obk``````
This function parameter attribute was introduced in https://github.com/rust-lang/rust/pull/44866 as an intermediate step in implementing `impl Trait`, it's not necessary or used anywhere by itself.
Because it's always `'tcx`. In fact, some of them use a mixture of
passed-in `$tcx` and hard-coded `'tcx`, so no other lifetime would even
work.
This makes the code easier to read.
Remove `DropArena`.
Most arena-allocate types that impl `Drop` get their own `TypedArena`, but a
few infrequently used ones share a `DropArena`. This sharing adds complexity
but doesn't help performance or memory usage. Perhaps it was more effective in
the past prior to some other improvements to arenas.
This commit removes `DropArena` and the sharing of arenas via the `few`
attribute of the `arena_types` macro. This change removes over 100 lines of
code and nine uses of `unsafe` (one of which affects the parallel compiler) and
makes the remaining code easier to read.
Most arena-allocate types that impl `Drop` get their own `TypedArena`, but a
few infrequently used ones share a `DropArena`. This sharing adds complexity
but doesn't help performance or memory usage. Perhaps it was more effective in
the past prior to some other improvements to arenas.
This commit removes `DropArena` and the sharing of arenas via the `few`
attribute of the `arena_types` macro. This change removes over 100 lines of
code and nine uses of `unsafe` (one of which affects the parallel compiler) and
makes the remaining code easier to read.
selection deduplicates obligations through a hashset at some point, computing the hashes for ObligationCauseCode
appears to dominate the hashing cost. bodyid + span + discriminant hash hopefully will sufficiently unique
unique enough.
