| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Fix const drop checking
Fixes confirmation of `~const Destruct` and const drops.
r? fee1-dead
|
|
Reverts #116530
|
|
split `NormalizesTo` out of `Projection` 3
third attempt at #112658. Rebasing #116262 is very annoying, so I am doing it again from scratch. We should now be able to merge it without regressing anything as we handle occurs check failures involving aliases correctly since #117088.
see https://hackmd.io/ktEL8knTSYmtdfrMMnA-Hg
fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/1
r? `@compiler-errors`
|
|
|
|
Only check principal trait ref for object safety
It should make things a bit faster, in case we end up registering a bunch of object safety preds.
r? ```@ghost```
|
|
|
|
|
|
`EvaluatedToUnknown` -> `EvaluatedToAmbigStackDependent`, `EvaluatedToRecur` -> `EvaluatedToErrStackDependent`
Less confusing names, since the only difference between them and their parallel `EvalutedTo..` is that they are stack dependent.
r? lcnr
|
|
Remove `PolyGenSig` since it's always a dummy binder
Coroutines are never polymorphic in their signature. This cleans up a FIXME in the code:
```
/// Returns the "coroutine signature", which consists of its yield
/// and return types.
///
/// N.B., some bits of the code prefers to see this wrapped in a
/// binder, but it never contains bound regions. Probably this
/// function should be removed.
```
|
|
|
|
EvaluatedToErrStackDependent
|
|
|
|
r=compiler-errors
Provide context when `?` can't be called because of `Result<_, E>`
When a method chain ending in `?` causes an E0277 because the expression's `Result::Err` variant doesn't have a type that can be converted to the `Result<_, E>` type parameter in the return type, provide additional context of which parts of the chain can and can't support the `?` operator.
```
error[E0277]: `?` couldn't convert the error to `String`
--> $DIR/question-mark-result-err-mismatch.rs:27:25
|
LL | fn bar() -> Result<(), String> {
| ------------------ expected `String` because of this
LL | let x = foo();
| ----- this has type `Result<_, String>`
...
LL | .map_err(|_| ())?;
| ---------------^ the trait `From<()>` is not implemented for `String`
| |
| this can't be annotated with `?` because it has type `Result<_, ()>`
|
= note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
= help: the following other types implement trait `From<T>`:
<String as From<char>>
<String as From<Box<str>>>
<String as From<Cow<'a, str>>>
<String as From<&str>>
<String as From<&mut str>>
<String as From<&String>>
= note: required for `Result<(), String>` to implement `FromResidual<Result<Infallible, ()>>`
```
Fix #72124.
|
|
|
|
Fix #72124.
|
|
|
|
When a method chain ending in `?` causes an E0277 because the
expression's `Result::Err` variant doesn't have a type that can be
converted to the `Result<_, E>` type parameter in the return type,
provide additional context of which parts of the chain can and can't
support the `?` operator.
```
error[E0277]: `?` couldn't convert the error to `String`
--> $DIR/question-mark-result-err-mismatch.rs:28:25
|
LL | fn bar() -> Result<(), String> {
| ------------------ expected `String` because of this
LL | let x = foo();
| ----- this can be annotated with `?` because it has type `Result<String, String>`
LL | let one = x
LL | .map(|s| ())
| ----------- this can be annotated with `?` because it has type `Result<(), String>`
LL | .map_err(|_| ())?;
| ---------------^ the trait `From<()>` is not implemented for `String`
| |
| this can't be annotated with `?` because it has type `Result<(), ()>`
|
= note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
= help: the following other types implement trait `From<T>`:
<String as From<char>>
<String as From<Box<str>>>
<String as From<Cow<'a, str>>>
<String as From<&str>>
<String as From<&mut str>>
<String as From<&String>>
= note: required for `Result<(), String>` to implement `FromResidual<Result<Infallible, ()>>`
```
Fix #72124.
|
|
r=lcnr
Add `deeply_normalize_for_diagnostics`, use it in coherence
r? lcnr
Normalize trait refs used for coherence error reporting with `-Ztrait-solver=next-coherence`.
Two things:
1. I said before that we can't add this to `TyErrCtxt` because we compute `OverlapResult`s even if there are no diagnostics being emitted, e.g. for a reservation impl.
2. I didn't want to add this to an `InferCtxtExt` trait because I felt it was unnecessary. I don't particularly care about the API though.
|
|
|
|
|
|
|
|
|
|
|
|
r=compiler-errors
Restrict what symbols can be used in `#[diagnostic::on_unimplemented]` format strings
This commit restricts what symbols can be used in a format string for any option of the `diagnostic::on_unimplemented` attribute. We previously allowed all the ad-hoc options supported by the internal `#[rustc_on_unimplemented]` attribute. For the stable attribute we only want to support generic parameter names and `{Self}` as parameters. For any other parameter an warning is emitted and the parameter is replaced by the literal parameter string, so for example `{integer}` turns into `{integer}`. This follows the general design of attributes in the `#[diagnostic]` attribute namespace, that any syntax "error" is treated as warning and subsequently ignored.
r? `@compiler-errors`
|
|
format strings
This commit restricts what symbols can be used in a format string for
any option of the `diagnostic::on_unimplemented` attribute. We
previously allowed all the ad-hoc options supported by the internal
`#[rustc_on_unimplemented]` attribute. For the stable attribute we only
want to support generic parameter names and `{Self}` as parameters. For
any other parameter an warning is emitted and the parameter is replaced
by the literal parameter string, so for example `{integer}` turns into
`{integer}`. This follows the general design of attributes in the
`#[diagnostic]` attribute namespace, that any syntax "error" is treated
as warning and subsequently ignored.
|
|
Fix ICE: `fn_arg_names: unexpected item DefId(..)`
Fixes #118510
|
|
|
|
Handle recursion limit for subtype and well-formed predicates
Adds a recursion limit check for subtype predicates and well-formed predicates.
`-Ztrait-solver=next` currently panics with unimplemented for these cases.
These cases are arguably bugs in the occurs check but:
- I could not find a simple way to fix the occurs check
- There should still be a recursion limit check to prevent hangs anyway.
closes #117151
r? types
|
|
Because the corresponding `Level` is `DelayedBug` and `span_delayed_bug`
follows the pattern used everywhere else: `span_err`, `span_warning`,
etc.
|
|
|
|
On Fn arg mismatch for a fn path, suggest a closure
When encountering a fn call that has a path to another fn being passed in, where an `Fn` impl is expected, and the arguments differ, suggest wrapping the argument with a closure with the appropriate arguments.
The last `help` is new:
```
error[E0631]: type mismatch in function arguments
--> $DIR/E0631.rs:9:9
|
LL | fn f(_: u64) {}
| ------------ found signature defined here
...
LL | foo(f);
| --- ^ expected due to this
| |
| required by a bound introduced by this call
|
= note: expected function signature `fn(usize) -> _`
found function signature `fn(u64) -> _`
note: required by a bound in `foo`
--> $DIR/E0631.rs:3:11
|
LL | fn foo<F: Fn(usize)>(_: F) {}
| ^^^^^^^^^ required by this bound in `foo`
help: consider wrapping the function in a closure
|
LL | foo(|arg0: usize| f(/* u64 */));
| +++++++++++++ +++++++++++
```
|
|
|
|
When encountering a fn call that has a path to another fn being passed
in, where an `Fn` impl is expected, and the arguments differ, suggest
wrapping the argument with a closure with the appropriate arguments.
|
|
|
|
Don't add redundant help for object safety violations
Fixes #117186
r? WaffleLapkin
|
|
r=compiler-errors
Do not erase late bound regions when selecting inherent associated types
In the fix for #97156 we would want the following code:
```rust
#![feature(inherent_associated_types)]
#![allow(incomplete_features)]
struct Foo<T>(T);
impl Foo<fn(&'static ())> {
type Assoc = u32;
}
trait Other {}
impl Other for u32 {}
// FIXME(inherent_associated_types): Avoid emitting two diagnostics (they only differ in span).
// FIXME(inherent_associated_types): Enhancement: Spruce up the diagnostic by saying something like
// "implementation is not general enough" as is done for traits via
// `try_report_trait_placeholder_mismatch`.
fn bar(_: Foo<for<'a> fn(&'a ())>::Assoc) {}
//~^ ERROR mismatched types
//~| ERROR mismatched types
fn main() {}
```
to fail with ...
```
error[E0220]: associated type `Assoc` not found for `Foo<for<'a> fn(&'a ())>` in the current scope
--> tests/ui/associated-inherent-types/issue-109789.rs:18:36
|
4 | struct Foo<T>(T);
| ------------- associated item `Assoc` not found for this struct
...
18 | fn bar(_: Foo<for<'a> fn(&'a ())>::Assoc) {}
| ^^^^^ associated item not found in `Foo<for<'a> fn(&'a ())>`
|
= note: the associated type was found for
- `Foo<fn(&'static ())>`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0220`.
```
This PR fixes the ICE we are currently getting "was a subtype of Foo<Binder(fn(&ReStatic ()), [])> during selection but now it is not"
Also fixes #112631
r? `@lcnr`
|
|
|
|
Clean dead codes
Clean dead codes detected by #118257
|
|
`AmbiguityCause` should not eagerly format strings
Minor tweak found when working on some coherence diagnostics stuff (towards `-Ztrait-solver=next-coherence` stabilization)
|
|
cleanup
|
|
|
|
Don't ICE when encountering placeholders in implied bounds computation
I *could* fix this the right way, though I don't really want to think about the implications of the change. This should have minimal side-effects.
r? `@aliemjay`
Fixes #118286
|
|
Use `is_{some,ok}_and` more in the compiler
slightly more fluent-reading code
|
|
Miscellaneous `ObligationCauseCode` cleanups
Remove some dead code/unused `ObligationCauseCode`s.
|
|
r=compiler-errors
Reduce fluent boilerplate
Best reviewed one commit at a time.
r? `@davidtwco`
|
|
|
|
|
|
|
|
Currently we always do this:
```
use rustc_fluent_macro::fluent_messages;
...
fluent_messages! { "./example.ftl" }
```
But there is no need, we can just do this everywhere:
```
rustc_fluent_macro::fluent_messages! { "./example.ftl" }
```
which is shorter.
|
