make test succeed on targets lacking a personality
Not all targets have `eh_personality` lang item set (see library/std/src/sys/personality/mod.rs), so change test to use a more available lang item.
The diagnostic is generally very noisy.
This commit tries to make it slightly less cluttered and more legible by
1. stopping to reuse the lengthy primary message as the primary label.
This duplication didn't increase the information content and only
turned the diagnostic into a letter and symbol soup.
Instead, we now pick a succinct label ("uncovered type parameter")
that immediately(!) signals to the users in red what is wrong with
the highlighted type parameter.
2. breaking some information-dense notes into multiple lines.
Finally, this rephrases the slightly awkward and confusing
"type parameter […] must be used as a type parameter for […] type" to
"type parameter […] must be used as an argument to […] type".
Use #[panic_handler] rather than #[lang = "panic_impl"]
As preparation for turning #[panic_handler] from a weak lang item into an EII.
r? @jdonszelmann
Rewrite the `#[repr]` attribute parser
The `#[repr]` attribute parser was one of the first attribute parsers we made, and didn't use a lot of the awesome infra we have nowadays yet, so in preparation for a new approach I'm trying for https://github.com/rust-lang/rust/pull/156569 I decided to clean it up.
This PR should have no observable effect other than improved diagnostic messages.
r? @mejrs
When an unconstrained type or lifetime parameter is detected in an
`impl`, provide more specific help based on its usage:
- If the parameter is entirely unused, suggest removing it.
- If it is used in the `impl` body but not the `Self` type, suggest
including it in the `Self` type and the struct definition.
This also adds a comprehensive UI test for these cases.
also removes E0452 and splits
`tests/rustdoc-ui/lints/renamed-lint-still-applies` into 2 tests
this is because of delayed warn lint being lost on compiler aborting on
error
Remove "failed to resolve" and use the same format we use in other resolution errors "cannot find `name`".
```
error[E0433]: cannot find `nonexistent` in `existent`
--> $DIR/custom_attr_multisegment_error.rs:5:13
|
LL | #[existent::nonexistent]
| ^^^^^^^^^^^ could not find `nonexistent` in `existent`
```
We used to lower such bad defaulted const args in trait object types to
`{type error}`; now correctly lower them to `{const error}`.
The added tests used to ICE prior to this change.
Better handle when trying to iterate on a `Range` of a type that isn't `Step`
Mention when a trait bound corresponds to an unstable trait.
Mention `Range` when `Step` bound is unment, and explain that only some std types impl `Iterator` for `Range`.
CC rust-lang/rust#151026
diagnostics: make implicit Sized bounds explicit in E0277
When a trait parameter depends upon Sized, the error message only referred to the full trait itself and didn't mention Sized. This makes the failure to implement Sized explicit. It also notes when the Sized trait bound is explicit or implicit.
Fixesrust-lang/rust#150576
When a trait parameter depends upon Sized, the error message only
referred to the full trait itself and didn't mention Sized. This makes
the failure to implement Sized explicit. It also notes when the Sized
trait bound is explicit or implicit.
Externally implementable items
Supersedes https://github.com/rust-lang/rust/pull/140010
Tracking issue: https://github.com/rust-lang/rust/issues/125418
Getting started:
```rust
#![feature(eii)]
#[eii(eii1)]
pub fn decl1(x: u64)
// body optional (it's the default)
{
println!("default {x}");
}
// in another crate, maybe
#[eii1]
pub fn decl2(x: u64) {
println!("explicit {x}");
}
fn main() {
decl1(4);
}
```
- tiny perf regression, underlying issue makes multiple things in the compiler slow, not just EII, planning to solve those separately.
- No codegen_gcc support, they don't have bindings for weak symbols yet but could
- No windows support yet for weak definitions
This PR merges the implementation of EII for just llvm + not windows, doesn't yet contain like a new panic handler implementation or alloc handler. With this implementation, it would support implementing the panic handler in terms of EII already since it requires no default implementation so no weak symbols
The PR has been open in various forms for about a year now, but I feel that having some implementation merged to build upon
Jonathan Brouwer