Add suggestions for unsafe impl error codes
Adds suggestions for users to add `unsafe` to trait impls that should be `unsafe`, and remove `unsafe` from trait impls that do not require `unsafe`
With the folllowing code:
```rust
struct Foo {}
struct Bar {}
trait Safe {}
unsafe trait Unsafe {}
impl Safe for Foo {} // ok
impl Unsafe for Foo {} // E0200
unsafe impl Safe for Bar {} // E0199
unsafe impl Unsafe for Bar {} // ok
// omitted empty main fn
```
The current rustc output is:
```
error[E0199]: implementing the trait `Safe` is not unsafe
--> e0200.rs:13:1
|
13 | unsafe impl Safe for Bar {} // E0199
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
error[E0200]: the trait `Unsafe` requires an `unsafe impl` declaration
--> e0200.rs:11:1
|
11 | impl Unsafe for Foo {} // E0200
| ^^^^^^^^^^^^^^^^^^^^^^
error: aborting due to 2 previous errors
Some errors have detailed explanations: E0199, E0200.
For more information about an error, try `rustc --explain E0199`.
```
With this PR, the future rustc output would be:
```
error[E0199]: implementing the trait `Safe` is not unsafe
--> ../../temp/e0200.rs:13:1
|
13 | unsafe impl Safe for Bar {} // E0199
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
help: remove `unsafe` from this trait implementation
|
13 - unsafe impl Safe for Bar {} // E0199
13 + impl Safe for Bar {} // E0199
|
error[E0200]: the trait `Unsafe` requires an `unsafe impl` declaration
--> ../../temp/e0200.rs:11:1
|
11 | impl Unsafe for Foo {} // E0200
| ^^^^^^^^^^^^^^^^^^^^^^
|
= note: the trait `Unsafe` enforces invariants that the compiler can't check. Review the trait documentation and make sure this implementation upholds those invariants before adding the `unsafe` keyword
help: add `unsafe` to this trait implementation
|
11 | unsafe impl Unsafe for Foo {} // E0200
| ++++++
error: aborting due to 2 previous errors
Some errors have detailed explanations: E0199, E0200.
For more information about an error, try `rustc --explain E0199`.
```
``@rustbot`` label +T-compiler +A-diagnostics +A-suggestion-diagnostics
Add flag to forbid recovery in the parser
To start the effort of fixing #103534, this adds a new flag to the parser, which forbids the parser from doing recovery, which it shouldn't do in macros.
This doesn't add any new checks for recoveries yet and is just here to bikeshed the names for the functions here before doing more.
r? `@compiler-errors`
rustc_metadata: Add struct and variant constructors to module children at encoding time
instead of decoding time.
Continuation of https://github.com/rust-lang/rust/pull/95899.
The last time it caused some ICEs from generator use, but not everything seems ok.
Clean up hidden type registration
work on https://github.com/rust-lang/rust/issues/101186
Actually passing down the relation and using it instead of `eq` for the hidden type comparison has *no* effect whatsoever and allows for no further improvements at the call sites. I decided the increased complexity was not worth it and thus did not include that change in this PR.
r? `@compiler-errors`
Rollup of 9 pull requests
Successful merges:
- #103035 (Even nicer errors from assert_unsafe_precondition)
- #103106 (Try to say that memory outside the AM is always exposed)
- #103475 (Make param index generation a bit more robust)
- #103525 (Move a wf-check into the site where the value is instantiated)
- #103564 (library: allow some unused things in Miri)
- #103586 (Process registered region obligation in `resolve_regions_with_wf_tys`)
- #103592 (rustdoc: remove redundant CSS selector `.notable-traits .notable`)
- #103593 (Remove an unused parser function (`Expr::returns`))
- #103611 (Add test for issue 103574)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Remove `commit_if_ok` probe from NLL type relation
It was not really necessary to add the `commit_if_ok` in #100092 -- I added it to protect us against weird inference error messages due to recursive RPIT calls, but we are always on the error path when this happens anyways, and I can't come up with an example that makes this manifest.
Fixes#103599
r? `@oli-obk` since you reviewed #100092, feel free to re-roll.
🅱️📢 beta-nominating this since it's on beta (which forks in ~a week~ two days 😨) -- worst case we could revert the original PR on beta and land this on nightly, to give it some extra soak time...
The current logic to ignore ThinLTO when `-Ccodegen-units=1` makes sense
for local ThinLTO but even in this scenario, a user may still want
(non-local) ThinLTO for the purpose of optimizing dependencies into the
final crate which is being compiled with 1 CGU.
The previous behavior was even more confusing because if you were
generating a binary (`--emit=link`), then you would get ThinLTO but if
you asked for LLVM IR or bytecode, then it would silently change to
using regular LTO.
With this change, we only override the defaults for local ThinLTO if you
ask for a single output such as LLVM IR or bytecode and in all other
cases honor the requested LTO setting.
