| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Suggest adding a type parameter for impls
Add a new suggestion upon encountering an unknown type in a `impl` that suggests adding a new type parameter. This diagnostic suggests to add a new type parameter even though it may be a const parameter, however after adding the parameter and running rustc again a follow up error steers the user to change the type parameter to a const parameter.
```rust
struct X<const C: ()>();
impl X<C> {}
```
suggests
```
error[E0412]: cannot find type `C` in this scope
--> bar.rs:2:8
|
1 | struct X<const C: ()>();
| ------------------------ similarly named struct `X` defined here
2 | impl X<C> {}
| ^
|
help: a struct with a similar name exists
|
2 | impl X<X> {}
| ^
help: you might be missing a type parameter
|
2 | impl<C> X<C> {}
| ^^^
```
After adding a type parameter the code now becomes
```rust
struct X<const C: ()>();
impl<C> X<C> {}
```
and the error now fully steers the user towards the correct code
```
error[E0747]: type provided when a constant was expected
--> bar.rs:2:11
|
2 | impl<C> X<C> {}
| ^
|
help: consider changing this type parameter to be a `const` generic
|
2 | impl<const C: ()> X<C> {}
| ^^^^^^^^^^^
```
r? `@estebank`
Somewhat related #84946
|
|
When there are multiple macros in use, it can be difficult to tell
which one was responsible for producing an error.
|
|
|
|
|
|
|
|
Update BARE_TRAIT_OBJECT and ELLIPSIS_INCLUSIVE_RANGE_PATTERNS to errors in Rust 2021
This addresses https://github.com/rust-lang/rust/pull/81244 by updating two lints to errors in the Rust 2021 edition.
r? `@estebank`
|
|
Add help message to suggest const for unused type param
r? `@lcnr`
|
|
|
|
Fix generic arg mismatch errors being ignored with explicit late bound lifetimes
Fixes #83466
r? `@varkor`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Also tweaked the message a bit by
- removing the hyphen, because in my opinion the hyphen makes the
message a bit harder to read, especially combined with the backticks;
- adding the word "be", because I think it's a bit clearer that way.
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #83065 (Rework `std::sys::windows::alloc`)
- #83478 (rustdoc: Add unstable option to only emit shared/crate-specific files)
- #83629 (Fix double-drop in `Vec::from_iter(vec.into_iter())` specialization when items drop during panic)
- #83673 (give full path of constraint in suggest_constraining_type_param)
- #83755 (Simplify coverage tests)
- #83757 (2229: Support migration via rustfix)
- #83771 (Fix stack overflow detection on FreeBSD 11.1+)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
revert file
bless with nll mode
|
|
|
|
|
|
combine: stop eagerly evaluating consts
`super_relate_consts` eagerly evaluates constants which doesn't seem too great.
I now also finally understand why all of the unused substs test passed. The reason being
that we just evaluated the constants in `super_relate_consts` :laughing:
While this change isn't strictly necessary as evaluating consts here doesn't hurt, it still feels a lot cleaner to do it this way
r? `@oli-obk` `@nikomatsakis`
|
|
|
|
|
|
Closes #56445.
|
|
|
|
|
|
A bunch of nits fixed, and a new test for pretty printing the AST.
|
|
|
|
|
|
|
|
This currently creates a field which is always false on GenericParamDefKind for future use when
consts are permitted to have defaults
Update const_generics:default locations
Previously just ignored them, now actually do something about them.
Fix using type check instead of value
Add parsing
This adds all the necessary changes to lower const-generics defaults from parsing.
Change P<Expr> to AnonConst
This matches the arguments passed to instantiations of const generics, and makes it specific to
just anonymous constants.
Attempt to fix lowering bugs
|
|
const_evaluatable_checked: Stop eagerly erroring in `is_const_evaluatable`
Fixes #82279
We don't want to be emitting errors inside of is_const_evaluatable because we may call this during selection where it should be able to fail silently
There were two errors being emitted in `is_const_evaluatable`. The one causing the compile error in #82279 was inside the match arm for `FailureKind::MentionsParam` but I moved the other error being emitted too since it made things cleaner imo
The `NotConstEvaluatable` enum \*should\* have a fourth variant for when we fail to evaluate a concrete const, e.g. `0 - 1` but that cant happen until #81339
cc `@oli-obk` `@lcnr`
r? `@nikomatsakis`
|
|
|
|
|
|
always eagerly eval consts in Relate
r? ```@nikomatsakis``` cc ```@varkor```
|
|
|
|
|
|
Use correct param_env in conservative_is_privately_uninhabited
cc `@lcnr`
r? `@varkor` since this is your FIXME that was removed ^^
|
|
|
|
const_generics: Dont evaluate array length const when handling yet another error
Same ICE as #82009 except triggered by a different error.
cc ``@lcnr``
r? ``@varkor``
|
|
Add diagnostics for specific cases for const/type mismatch err
For now, this adds at least more information so better diagnostics can be emitted for const mismatch errors.
I'm not sure what exactly we want to emit, so I've left notes there temporarily, also to see if this is the right approach
r? ```@lcnr```
cc: ```@estebank```
|
|
|
|
|
|
const_generics: Fix incorrect ty::ParamEnv::empty() usage
Fixes #80561
Not sure if I should keep the `debug!(..)`s or not but its the second time I've needed them so they sure seem useful lol
cc ``@lcnr``
r? ``@oli-obk``
|
