Use annotate-snippet as default emitter on stable
This is implementation of https://github.com/rust-lang/rust/issues/149932
Now, after MCP was accepted, we can use annotate-snippet as default emitter for errors, that means that we not longer need of previous emitter, so this PR removed previous emitter and makes annotate-snippet new default one both on stable and nightly
(this PR does not remove a code of previous emitter it just removes a `Default` option of `HumanReadableErrorType` enum, and keeping only `HumanReadableErrorType::AnnotateSnippet` as it now uses by default)
```
error[E0308]: mismatched types
--> $DIR/macro-span-caller-replacement.rs:5:17
|
LL | s = format!("{arg}");
| ^^^^^^^^^^^^^^^^ expected `&str`, found `String`
...
LL | macro_with_format!();
| -------------------- in this macro invocation
|
= note: this error originates in the macro `format` which comes from the expansion of the macro `macro_with_format` (in Nightly builds, run with -Z macro-backtrace for more info)
```
Add regression test for 141845
close: rust-lang/rust#141845
I saw the `tests/ui/associated-inherent-types` directory, but I felt the current location was a better fit.
mgca: Finish implementation of `#[type_const]`
tracking issue: rust-lang/rust#132980fixesrust-lang/rust#140729fixesrust-lang/rust#140860
- **Fix `#[type_const]` attribute placement validation**
- **Perform WF-checking on type_const RHS's**
- **Check type_const type is ConstParamTy_ and that RHS matches it**
- **Check that impls of `#[type_const]` consts also have the attr**
r? ```@BoxyUwU```
Remove `#[const_trait]`
Remove `#[const_trait]` since we now have `const trait`. Update all structured diagnostics that still suggested the attribute.
r? ```@rust-lang/project-const-traits```
mgca: Add ConstArg representation for const items
tracking issue: rust-lang/rust#132980fixesrust-lang/rust#131046fixesrust-lang/rust#134641
As part of implementing `min_generic_const_args`, we need to distinguish const items that can be used in the type system, such as in associated const equality projections, from const items containing arbitrary const code, which must be kept out of the type system. Specifically, all "type consts" must be either concrete (no generics) or generic with a trivial expression like `N` or a path to another type const item.
To syntactically distinguish these cases, we require, for now at least, that users annotate all type consts with the `#[type_const]` attribute. Then, we validate that the const's right-hand side is indeed eligible to be a type const and represent it differently in the HIR.
We accomplish this representation using a new `ConstItemRhs` enum in the HIR, and a similar but simpler enum in the AST. When `#[type_const]` is **not** applied to a const (e.g. on stable), we represent const item right-hand sides (rhs's) as HIR bodies, like before. However, when the attribute is applied, we instead lower to a `hir::ConstArg`. This syntactically distinguishes between trivial const args (paths) and arbitrary expressions, which are represented using `AnonConst`s. Then in `generics_of`, we can take advantage of the existing machinery to bar the `AnonConst` rhs's from using parent generics.
Tweak E0401
More accurate span pointing at use place of outer param (at ident instead of full path).
Add note explaining why outer item params can't be used in inner item.
Use structured suggestion for what `Self` should have been.
Follow up to rust-lang/rust#148370.
Fixrust-lang/rust#37892.
Point at inner item when it uses generic type param from outer item or `Self`
Partially address rust-lang/rust#37892.
In E0401 generated in resolve:
```
error[E0401]: can't use generic parameters from outer item
--> $DIR/E0401.rs:4:39
|
LL | fn foo<T>(x: T) {
| - type parameter from outer item
LL | fn bfnr<U, V: Baz<U>, W: Fn()>(y: T) {
| ---- ^ use of generic parameter from outer item
| |
| generic parameter used in this inner function
|
help: try introducing a local generic parameter here
|
LL | fn bfnr<T, U, V: Baz<U>, W: Fn()>(y: T) {
| ++
```
In E0401 generated in hir_typeck:
```
error[E0401]: can't reference `Self` constructor from outer item
--> $DIR/do-not-ice-on-note_and_explain.rs:6:13
|
LL | impl<B> A<B> {
| ------------ the inner item doesn't inherit generics from this impl, so `Self` is invalid to reference
LL | fn d() {
LL | fn d() {
| - `Self` used in this inner item
LL | Self(1)
| ^^^^ help: replace `Self` with the actual type: `A`
```
Do not emit solver errors that contain error types
any follow-up errors are going to either be duplicates or often disappear if the error itself is fixed.
in this PR it mostly silences dyn-compat errors as all the other errors are already deduplicated outside of the test suite. The dyn compat errors are independent errors and I think if the dyn compatiblity depended on an error type it would not actually show, so this is PR is actually silencing independent errors, too.
I am opening this PR because I am seeing lots of `{type error}: const Trait` errors when adding more const checking. So instead of targetting just those specific errors, I wanted to try out fully avoiding such errors near the trait solver.
cc ````@rust-lang/types```` for thoughts
```
error[E0277]: the trait bound `[[u16; 3]; 2]: Bar` is not satisfied
--> $DIR/issue-67185-2.rs:21:6
|
LL | impl Foo for FooImpl {}
| ^^^ the trait `Bar` is not implemented for `[[u16; 3]; 2]`
|
help: the following other types implement trait `Bar`
--> $DIR/issue-67185-2.rs:9:1
|
LL | impl Bar for [u16; 4] {}
| ^^^^^^^^^^^^^^^^^^^^^ `[u16; 4]`
LL | impl Bar for [[u16; 3]; 3] {}
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ `[[u16; 3]; 3]`
note: required by a bound in `Foo`
--> $DIR/issue-67185-2.rs:14:30
|
LL | trait Foo
| --- required by a bound in this trait
LL | where
LL | [<u8 as Baz>::Quaks; 2]: Bar,
| ^^^ required by this bound in `Foo`
```
```
error[E0277]: the trait bound `u32: Trait` is not satisfied
--> $DIR/trait_objects_fail.rs:26:9
|
LL | foo(&10_u32);
| ^^^^^^^ the trait `Trait` is not implemented for `u32`
|
help: the trait `Trait<12>` is not implemented for `u32`
but trait `Trait<2>` is implemented for it
--> $DIR/trait_objects_fail.rs:7:1
|
LL | impl Trait<2> for u32 {}
| ^^^^^^^^^^^^^^^^^^^^^
= note: required for the cast from `&u32` to `&dyn Trait`
```
Pointing at the `impl` definition that *could* apply given a different self type is particularly useful when it has a blanket self type, as it might not be obvious and is not trivially greppable:
```
error[E0277]: the trait bound `RawImpl<_>: Raw<_>` is not satisfied
--> $DIR/issue-62742.rs:4:5
|
LL | WrongImpl::foo(0i32);
| ^^^^^^^^^ unsatisfied trait bound
|
help: the trait `Raw<_>` is not implemented for `RawImpl<_>`
but trait `Raw<[_]>` is implemented for it
--> $DIR/issue-62742.rs:29:1
|
LL | impl<T> Raw<[T]> for RawImpl<T> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: required by a bound in `SafeImpl`
--> $DIR/issue-62742.rs:33:35
|
LL | pub struct SafeImpl<T: ?Sized, A: Raw<T>>(PhantomData<(A, T)>);
| ^^^^^^ required by this bound in `SafeImpl`
```
Rehome 26 `tests/ui/issues/` tests to other subdirectories under `tests/ui/` [#5 of Batch #2]
Part of rust-lang/rust#133895
Methodology:
1. Refer to the previously written `tests/ui/SUMMARY.md`
2. Find an appropriate category for the test, using the original issue thread and the test contents.
3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers)
4. Rename the tests to make their purpose clearer
Inspired by the methodology that Kivooeo was using.
r? ```@jieyouxu```
Improve derive suggestion of const param
Make the suggestion not to remove the adt and use the name of the adt variant in the diagnostic.
r? `@BoxyUwU`
Migrate `UnsizedConstParamTy` to unstable impl of `ConstParamTy_`
Now that we have ``#[unstable_feature_bound]``, we can remove ``UnsizedConstParamTy`` that was meant to be an unstable impl of stable type and ``ConstParamTy_`` trait.
r? `@BoxyUwU`
Jonathan Brouwer