Always print '_, even for erased lifetimes.
Explicit lifetime arguments are now the recommended syntax in rust 2018 and rust 2021. This PR applies this discipline to rustc itself.
Introduce mir::Unevaluated
Previously the distinction between unevaluated constants in the type-system and in mir was not explicit and a little confusing. Probably better to introduce its own type for that.
r? `@lcnr`
Rollup of 8 pull requests
Successful merges:
- #100734 (Split out async_fn_in_trait into a separate feature)
- #101664 (Note if mismatched types have a similar name)
- #101815 (Migrated the rustc_passes annotation without effect diagnostic infrastructure)
- #102042 (Distribute rust-docs-json via rustup.)
- #102066 (rustdoc: remove unnecessary `max-width` on headers)
- #102095 (Deduplicate two functions that would soon have been three)
- #102104 (Set 'exec-env:RUST_BACKTRACE=0' in const-eval-select tests)
- #102112 (Allow full relro on powerpc64-unknown-linux-gnu)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Improve the help message for an invalid calling convention
Fixes https://github.com/rust-lang/rust/issues/93601
I mostly followed the suggestions of `@nagisa` in that issue, ~~however, I wasn't sure how to check stability for the suggestion of "Do not suggest CCs that cannot be used due to them being unstable and feature not being enabled", so I did not implement that point.~~
I haven't contributed to rustc much, please feel free to point out suggestions! For example, the `.map(|s| Symbol::intern(s)).collect::<Vec<_>>()` seems pretty gross performance-wise, but maybe that's OK in error reporting code.
Allow full relro on powerpc64-unknown-linux-gnu
This was previously limited to partial relro, citing issues on RHEL6,
but that's no longer a supported platform since #95026. We have long
been enabling full relro in RHEL7's own Rust builds for ppc64, without
trouble, so it should be fine to drop this workaround.
Migrated the rustc_passes annotation without effect diagnostic infrastructure
Small change to move the validation for annotations to the new diagnostic infrastructure.
Note if mismatched types have a similar name
If users get a type error between similarly named types, it will point out that these are actually different types, and where they were defined.
Split out async_fn_in_trait into a separate feature
PR #101224 added support for async fn in trait desuraging behind the `return_position_impl_trait_in_trait` feature.
Split this out so that it's behind its own feature gate, since async fn in trait doesn't need to follow the same stabilization schedule.
Const unification is already infallible, remove the error handling logic
r? `@lcnr`
is this expected to be used in the future? Right now it is dead code.
Inline SyntaxContext in both encoded span representation.
The current interned representation for spans does not use the `ctxt_or_zero: u16` field. This PR proposes to use this field to store the `SyntaxContext` of the interned span instead. When `ctxt_or_zero` and the interned span's `ctxt` don't match, the inlined one takes precedence.
This allows to implement `Span::ctxt` and `Span::with_ctxt` with much less probability to access the interner. Those functions are used a lot for hygiene, so this may be worth it.
Rollup of 8 pull requests
Successful merges:
- #101598 (Update rustc's information on Android's sanitizers)
- #102036 (Remove use of `io::ErrorKind::Other` in std)
- #102037 (Make cycle errors recoverable)
- #102069 (Skip `Equate` relation in `handle_opaque_type`)
- #102076 (rustc_transmute: fix big-endian discriminants)
- #102107 (Add missing space between notable trait tooltip and where clause)
- #102119 (Fix a typo “pararmeter” in error message)
- #102131 (Added which number is computed in compute_float.)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
rustc_transmute: fix big-endian discriminants
I noticed that some new tests were failing in Fedora on s390x only, which usually means there's a problem with big-endian, and sure enough there's a FIXME(``@jswrenn)`` for that in `rustc_transmute`. This patch implements the appropriate consideration for target endianness, rather than using native (host) endian.
Make cycle errors recoverable
In particular, this allows rustdoc to recover from cycle errors when normalizing associated types for documentation.
In the past, ```@jackh726``` has said we need to be careful about overflow errors: https://github.com/rust-lang/rust/pull/91430#issuecomment-983997013
> Off the top of my head, we definitely should be careful about treating overflow errors the same as
"not implemented for some reason" errors. Otherwise, you could end up with behavior that is
different depending on recursion depth. But, that might be context-dependent.
But cycle errors should be safe to unconditionally report; they don't depend on the recursion depth, they will always be an error whenever they're encountered.
Helps with https://github.com/rust-lang/rust/issues/81091.
r? ```@lcnr``` cc ```@matthewjasper```
Update rustc's information on Android's sanitizers
This patch updates sanitizer support definitions for Android inside the compiler. It also adjusts the logic to make sure no pre-built sanitizer runtime libraries are emitted as these are instead provided dynamically on Android targets.
Normalize opaques w/ bound vars
First, we reenable normalization of opaque types with escaping late bound regions to fix rust-lang/miri#2433. This essentially reverts #89285.
Second, we mitigate the perf regression found in #88862 by simplifying the way that we relate (sub and eq) GeneratorWitness types.
This relies on the fact that we construct these GeneratorWitness types somewhat particularly (with all free regions found in the witness types replaced with late bound regions) -- but those bound regions really should be treated as existential regions, not universal ones. Those two facts leads me to believe that we do not need to use the full `higher_ranked_sub` machinery to relate two generator witnesses. I'm pretty confident that this is correct, but I'm glad to discuss this further.
use partition_point instead of binary_search when looking up source lines
In local benchmarks this results in 0.4% fewer cycles in a critical sequential section when compiling libcore.
PR #101224 added support for async fn in trait desuraging behind the
return_position_impl_trait_in_trait feature.
Split this out so that it's behind its own feature gate, since async fn
in trait doesn't need to follow the same stabilization schedule.
Move and rename `SessionDiagnostic` & `SessionSubdiagnostic` traits and macros
After PR #101434, we want to:
- [x] Move `SessionDiagnostic` to `rustc_errors`.
- [x] Add `emit_` methods that accept `impl SessionDiagnostic` to `Handler`.
- [x] _(optional)_ Rename trait `SessionDiagnostic` to `DiagnosticHandler`.
- [x] _(optional)_ Rename macro `SessionDiagnostic` to `DiagnosticHandler`.
- [x] Update Rustc Dev Guide and Docs to reflect these changes. https://github.com/rust-lang/rustc-dev-guide/pull/1460
Now I am having build issues getting the compiler to build when trying to rename the macro.
<details>
<summary>See diagnostics errors and context when building.</summary>
```
error: diagnostics should only be created in `SessionDiagnostic`/`AddSubdiagnostic` impls
--> compiler/rustc_attr/src/session_diagnostics.rs:13:10
|
13 | #[derive(DiagnosticHandler)]
| ^^^^^^^^^^^^^^^^^ in this derive macro expansion
|
::: /Users/jhonny/.cargo/registry/src/github.com-1ecc6299db9ec823/synstructure-0.12.6/src/macros.rs:94:9
|
94 | / pub fn $derives(
95 | | i: $crate::macros::TokenStream
96 | | ) -> $crate::macros::TokenStream {
| |________________________________________- in this expansion of `#[derive(DiagnosticHandler)]`
|
note: the lint level is defined here
--> compiler/rustc_attr/src/lib.rs:10:9
|
10 | #![deny(rustc::diagnostic_outside_of_impl)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
And also this one:
```
error: diagnostics should only be created in `SessionDiagnostic`/`AddSubdiagnostic` impls
--> compiler/rustc_attr/src/session_diagnostics.rs:213:32
|
213 | let mut diag = handler.struct_span_err_with_code(
| ^^^^^^^^^^^^^^^^^^^^^^^^^
```
> **Note**
> Can't find where this message is coming from, because you can see in [this experimental branch](https://github.com/JhonnyBillM/rust/tree/experimental/trying-to-rename-session-diagnostic-macro) that I updated all errors and diags to say:
> error: diagnostics should only be created in **`DiagnosticHandler`**/`AddSubdiagnostic` impls
> and not:
> error: diagnostics should only be created in **`SessionDiagnostic`**/`AddSubdiagnostic` impls
</details>
I tried building the compiler in different ways (playing with the stages etc), but nothing worked.
## Question
**Do we need to build or do something different when renaming a macro and identifiers?**
For context, see experimental commit f2193a98b4 where the macro and symbols are renamed, but it doesn't compile.
