Commit Graph

1328 Commits

Author SHA1 Message Date
Lukas Markeffsky
0c1f401d98 old solver: improve normalization of Pointee::Metadata 2024-02-05 15:37:21 +01:00
Oli Scherer
83738a9b1c Stop bailing out from compilation just because there were incoherent traits 2024-02-05 10:17:31 +00:00
bors
4d87c4ad62 Auto merge of #120649 - matthiaskrgr:rollup-ek80j61, r=matthiaskrgr
Rollup of 8 pull requests

Successful merges:

 - #119759 (Add FileCheck annotations to dataflow-const-prop tests)
 - #120323 (On E0277 be clearer about implicit `Sized` bounds on type params and assoc types)
 - #120473 (Only suggest removal of `as_*` and `to_` conversion methods on E0308)
 - #120540 (add test for try-block-in-match-arm)
 - #120547 (`#![feature(inline_const_pat)]` is no longer incomplete)
 - #120552 (Correctly check `never_type` feature gating)
 - #120555 (put pnkfelix (me) back on the review queue.)
 - #120556 (Improve the diagnostics for unused generic parameters)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-02-04 22:55:40 +00:00
Matthias Krüger
7d516c57df Rollup merge of #120531 - oli-obk:track_errors7, r=estebank
Remove a bunch of `has_errors` checks that have no meaningful or the wrong effect

r? `@nnethercote`
2024-02-03 22:25:16 +01:00
Michael Goulet
6dea155479 No need to validate_alias_bound_self_from_param_env in assemble_alias_bound_candidates 2024-02-03 01:21:19 +00:00
Michael Goulet
e951bcff96 Normalize the whole PolyTypeOutlivesPredicate, more simplifications 2024-02-02 18:31:35 +00:00
Michael Goulet
7d1fda7b40 Normalize type outlives obligations in NLL 2024-02-02 18:30:21 +00:00
Michael Goulet
0e16885abd Use deeply_normalize_with_skipped_universes in when processing type outlives 2024-02-02 18:30:21 +00:00
Esteban Küber
8b0ab54ffe review comment: change wording 2024-02-01 03:31:03 +00:00
Esteban Küber
c4c22b0d52 On E0277 be clearer about implicit Sized bounds on type params and assoc types
```
error[E0277]: the size for values of type `[i32]` cannot be known at compilation time
   --> f100.rs:2:33
    |
2   |     let _ = std::mem::size_of::<[i32]>();
    |                                 ^^^^^ doesn't have a size known at compile-time
    |
    = help: the trait `Sized` is not implemented for `[i32]`
note: required by an implicit `Sized` bound in `std::mem::size_of`
   --> /home/gh-estebank/rust/library/core/src/mem/mod.rs:312:22
    |
312 | pub const fn size_of<T>() -> usize {
    |                      ^ required by the implicit `Sized` requirement on this bound in `size_of`
```

Fix #120178.
2024-02-01 03:30:26 +00:00
Oli Scherer
d31905c904 Remove a has_errors check that doesn't actually prevent noisy follow up errors 2024-01-31 17:00:59 +00:00
Nadrieril
032596e34c Rollup merge of #120472 - Nilstrieb:die, r=compiler-errors
Make duplicate lang items fatal

Prevents terminal spam.
2024-01-31 12:10:52 +01:00
Nadrieril
0313eb2182 Rollup merge of #120469 - estebank:issue-40120, r=TaKO8Ki
Provide more context on derived obligation error primary label

Expand the primary span of E0277 when the immediate unmet bound is not what the user wrote:

```
error[E0277]: the trait bound `i32: Bar` is not satisfied
 --> f100.rs:6:6
  |
6 |     <i32 as Foo>::foo();
  |      ^^^ the trait `Bar` is not implemented for `i32`, which is required by `i32: Foo`
  |
help: this trait has no implementations, consider adding one
 --> f100.rs:2:1
  |
2 | trait Bar {}
  | ^^^^^^^^^
note: required for `i32` to implement `Foo`
 --> f100.rs:3:14
  |
3 | impl<T: Bar> Foo for T {}
  |         ---  ^^^     ^
  |         |
  |         unsatisfied trait bound introduced here
```

Fix #40120.
2024-01-31 12:10:51 +01:00
Esteban Küber
6efddac288 Provide more context on derived obligation error primary label
Expand the primary span of E0277 when the immediate unmet bound is not what the user wrote:

```
error[E0277]: the trait bound `i32: Bar` is not satisfied
 --> f100.rs:6:6
  |
6 |     <i32 as Foo>::foo();
  |      ^^^ the trait `Bar` is not implemented for `i32`, which is required by `i32: Foo`
  |
help: this trait has no implementations, consider adding one
 --> f100.rs:2:1
  |
2 | trait Bar {}
  | ^^^^^^^^^
note: required for `i32` to implement `Foo`
 --> f100.rs:3:14
  |
3 | impl<T: Bar> Foo for T {}
  |         ---  ^^^     ^
  |         |
  |         unsatisfied trait bound introduced here
```

Fix #40120.
2024-01-30 21:28:18 +00:00
Esteban Küber
5c414094ac Account for non-overlapping unmet trait bounds in suggestion
When a method not found on a type parameter could have been provided by any
of multiple traits, suggest each trait individually, instead of a single
suggestion to restrict the type parameter with *all* of them.

Before:

```
error[E0599]: the method `cmp` exists for reference `&T`, but its trait bounds were not satisfied
  --> $DIR/method-on-unbounded-type-param.rs:5:10
   |
LL |     (&a).cmp(&b)
   |          ^^^ method cannot be called on `&T` due to unsatisfied trait bounds
   |
   = note: the following trait bounds were not satisfied:
           `T: Ord`
           which is required by `&T: Ord`
           `&T: Iterator`
           which is required by `&mut &T: Iterator`
           `T: Iterator`
           which is required by `&mut T: Iterator`
help: consider restricting the type parameters to satisfy the trait bounds
   |
LL | fn g<T>(a: T, b: T) -> std::cmp::Ordering where T: Iterator, T: Ord {
   |                                           +++++++++++++++++++++++++
```

After:

```
error[E0599]: the method `cmp` exists for reference `&T`, but its trait bounds were not satisfied
  --> $DIR/method-on-unbounded-type-param.rs:5:10
   |
LL |     (&a).cmp(&b)
   |          ^^^ method cannot be called on `&T` due to unsatisfied trait bounds
   |
   = note: the following trait bounds were not satisfied:
           `T: Ord`
           which is required by `&T: Ord`
           `&T: Iterator`
           which is required by `&mut &T: Iterator`
           `T: Iterator`
           which is required by `&mut T: Iterator`
   = help: items from traits can only be used if the type parameter is bounded by the trait
help: the following traits define an item `cmp`, perhaps you need to restrict type parameter `T` with one of them:
   |
LL | fn g<T: Ord>(a: T, b: T) -> std::cmp::Ordering {
   |       +++++
LL | fn g<T: Iterator>(a: T, b: T) -> std::cmp::Ordering {
   |       ++++++++++
```

Fix #108428.
2024-01-30 19:26:13 +00:00
bors
cb4d9a1902 Auto merge of #119101 - compiler-errors:outlives, r=lcnr
Normalize region obligation in lexical region resolution with next-gen solver

This normalizes region obligations when we `resolve_regions`, since they may be unnormalized with deferred projection equality.

It's pretty hard to add tests that exercise this without also triggering MIR borrowck errors (because we don't normalize there yet). I've added one test with two revisions that should test that we both 1. normalize region obligations in the param env, and 2. normalize registered region obligations during lexical region resolution.
2024-01-30 19:22:04 +00:00
Esteban Küber
9ccc77036a fix rebase 2024-01-30 19:13:11 +00:00
Esteban Küber
20b1c2aafc Account for unbounded type param receiver in suggestions
When encountering

```rust
fn f<T>(a: T, b: T) -> std::cmp::Ordering {
    a.cmp(&b) //~ ERROR E0599
}
```

output

```
error[E0599]: no method named `cmp` found for type parameter `T` in the current scope
  --> $DIR/method-on-unbounded-type-param.rs:2:7
   |
LL | fn f<T>(a: T, b: T) -> std::cmp::Ordering {
   |      - method `cmp` not found for this type parameter
LL |     a.cmp(&b)
   |       ^^^ method cannot be called on `T` due to unsatisfied trait bounds
   |
   = help: items from traits can only be used if the type parameter is bounded by the trait
help: the following traits define an item `cmp`, perhaps you need to restrict type parameter `T` with one of them:
   |
LL | fn f<T: Ord>(a: T, b: T) -> std::cmp::Ordering {
   |       +++++
LL | fn f<T: Iterator>(a: T, b: T) -> std::cmp::Ordering {
   |       ++++++++++
```

Fix #120186.
2024-01-30 19:07:18 +00:00
Esteban Küber
d34b0fa495 Add test for method on unbounded type parameter receiver 2024-01-30 19:07:18 +00:00
Guillaume Gomez
f3f1472678 Rollup merge of #120476 - compiler-errors:lang-items-yeet, r=Nilstrieb
Remove some unnecessary check logic for lang items in HIR typeck

Obvious bugs with `#[no_core]` do not deserve customized recovery logic, since they are bugs we do not expect users to ever encounter, and if users are experimenting with `#[no_core]`, they should really be familiar with the compiler implementation.

These error recoveries are implemented now only where issues have been reported in the past, rather than systematically validating lang items.

See https://github.com/rust-lang/compiler-team/issues/620
> In particular, one-off fixes for particular assumptions about lang items or intrinsics that introduce additional complexity into the compiler are not accepted.

r? Nilstrieb
2024-01-30 16:57:51 +01:00
Guillaume Gomez
0a4fd52c91 Rollup merge of #120293 - estebank:issue-102629, r=nnethercote
Deduplicate more sized errors on call exprs

Change the implicit `Sized` `Obligation` `Span` for call expressions to include the whole expression. This aids the existing deduplication machinery to reduce the number of errors caused by a single unsized expression.
2024-01-30 16:57:47 +01:00
Guillaume Gomez
f7043a41ce Rollup merge of #120400 - estebank:bound-error-cleanup, r=oli-obk
Bound errors span label cleanup

Consolidate span labels for "this type doesn't satisfy a bound" for more compact diagnostic output.
2024-01-30 11:19:15 +01:00
bors
c401f09979 Auto merge of #119744 - lcnr:assemble-only-rigid, r=compiler-errors
only assemble alias bound candidates for rigid aliases

fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/77

This also causes `<Wrapper<?0> as Trait>::Unwrap: Trait` to always be ambig, as we now normalize the self type before checking whether it is an inference variable.

I cannot think of an approach to the underlying issues here which does not require the "may-define means must-define" restriction for opaque types. Going to go ahead with this and added this restriction to the tracking issue for the new solver to make sure we don't stabilize it without getting types + lang signoff here.

r? `@compiler-errors`
2024-01-30 07:11:24 +00:00
Michael Goulet
720d7a7a03 Apply suggestions from review 2024-01-30 00:09:58 +00:00
Michael Goulet
dc050f6d5b Add a test 2024-01-30 00:06:53 +00:00
Michael Goulet
028d29301f Deeply normalize when processing registered region obligations 2024-01-30 00:06:53 +00:00
Michael Goulet
b4efe07006 Remove some unnecessary check logic for lang items in HIR typeck 2024-01-29 19:48:44 +00:00
Nilstrieb
a360ecd64b Delete now-useless test
The test was using an internal feature which doesn't really matter, but
more importantly, we're now fatally exiting after the duplicate lang
item, so this tests nothing.
2024-01-29 20:06:26 +01:00
Nilstrieb
ad1e6298ed Make duplicate lang items fatal
Prevents terminal spam.
2024-01-29 20:03:14 +01:00
Esteban Küber
09f16b596d Avoid ICE in trait without dyn lint
Do not attempt to provide an accurate suggestion for `impl Trait`
in bare trait types when linting. Instead, only do the object
safety check when an E0782 is already going to be emitted in the
2021 edition.

Fix #120241.
2024-01-29 18:33:52 +00:00
lcnr
0d71860368 bye bye assemble_candidates_via_self_ty 2024-01-29 14:32:06 +01:00
Markus Reiter
021739c840 Update tests. 2024-01-27 16:38:57 +01:00
Matthias Krüger
fad940029b Rollup merge of #120378 - lcnr:normalize-ast, r=compiler-errors
always normalize `LoweredTy` in the new solver

I currently expect us to stop using alias bound candidates of normalizable aliases due to https://github.com/rust-lang/trait-system-refactor-initiative/issues/77 by landing https://github.com/rust-lang/rust/pull/119744. At this point it mostly doesn't matter whether we eagerly normalize (and replace with infer vars in case of ambiguity). cc #113473 previous attempt

The infer var replacement for ambiguous projections can in very rare cases:
- weaken inference https://github.com/rust-lang/trait-system-refactor-initiative/issues/81
- strengthen inference https://github.com/rust-lang/trait-system-refactor-initiative/issues/7

I do not expect this impact on inference to significantly affect real crates.

r? ``@compiler-errors``
2024-01-26 23:15:52 +01:00
Esteban Küber
757b726f86 Use only one label for multiple unsatisfied bounds on type (typeck) 2024-01-26 20:47:19 +00:00
lcnr
7b6ac8bf21 remove unnecessary test 2024-01-26 15:55:23 +01:00
lcnr
e87b8c7f34 move alias-relate tests 2024-01-26 15:55:23 +01:00
lcnr
a39a2f73d6 next-solver: normalize in LoweredTy::from_raw 2024-01-26 15:54:57 +01:00
Michal Nazarewicz
c4208fad3c bless 2024-01-25 16:41:17 +01:00
Esteban Küber
a9841936fe Deduplicate more sized errors on call exprs
Change the implicit `Sized` `Obligation` `Span` for call expressions to
include the whole expression. This aids the existing deduplication
machinery to reduce the number of errors caused by a single unsized
expression.
2024-01-24 02:53:15 +00:00
Oli Scherer
483382b93e Add regression test 2024-01-22 14:24:31 +00:00
Oli Scherer
9a20cf1697 Revert "Auto merge of #118133 - Urgau:stabilize_trait_upcasting, r=WaffleLapkin"
This reverts commit 6d2b84b3ed, reversing
changes made to 73bc12199e.
2024-01-22 14:24:31 +00:00
bors
533cfde67c Auto merge of #119947 - compiler-errors:old-solver-instantiate-response, r=lcnr
Make sure to instantiate placeholders correctly in old solver

When creating the query substitution guess for an input placeholder type like `!1_T` (in universe 1), we were guessing the response substitution with something like `!0_T`. This failed to unify with `!1_T`, causing an ICE.

This PR reworks the query substitution guess code to work a bit more like the new solver. I'm *pretty* sure this is correct, though I'd really appreciate some scrutiny from someone (*cough* lcnr) who knows a bit more about query instantiation :)

Fixes #119941

r? lcnr
2024-01-16 13:33:04 +00:00
Michael Goulet
985e1e031b Add a simpler test 2024-01-13 23:09:37 +00:00
Michael Goulet
24c1f4aa80 Make sure to instantiate placeholders correctly in old solver 2024-01-13 22:57:44 +00:00
bors
d78329b92e Auto merge of #119088 - George-lewis:glewis/suggest-upgrading-compiler, r=Nilstrieb
Suggest Upgrading Compiler for Gated Features

This PR addresses #117318

I have a few questions:

1. Do we want to specify the current version and release date of the compiler? I have added this in via environment variables, which I found in the code for the rustc cli where it handles the `--version` flag
  a. How can I handle the changing message in the tests?
3. Do we want to only show this message when the compiler is old?
  a. How can we determine when the compiler is old?

I'll wait until we figure out the message to bless the tests
2024-01-13 20:06:03 +00:00
George-lewis
d56cdd48cb Bless tests
Update tests
2024-01-13 12:46:58 -05:00
Matthias Krüger
9696ef7c12 Rollup merge of #119896 - oli-obk:variance_ice, r=compiler-errors
Taint `_` placeholder types in trait impl method signatures

We report an error right below for them, but that kind of broken type can cause subsequent ICEs.

fixes #119867
2024-01-13 15:10:29 +01:00
Oli Scherer
4586fdce47 Taint _ placeholder types 2024-01-12 16:33:29 +00:00
Guillaume Gomez
46c3c014eb Rollup merge of #119817 - compiler-errors:normalize-opaques, r=lcnr
Remove special-casing around `AliasKind::Opaque` when structurally resolving in new solver

This fixes a few inconsistencies around where we don't eagerly resolve opaques to their (locally-defined) hidden types in the new solver. It essentially allows this code to work:
```rust
fn main() {
    type Tait = impl Sized;
    struct S {
        i: i32,
    }
    let x: Tait = S { i: 0 };
    println!("{}", x.i);
}
```

Since `Tait` is defined in `main`, we are able to poke through the type of `x` with deref.

r? lcnr
2024-01-12 15:16:56 +01:00
bors
2b1365b34f Auto merge of #119735 - lcnr:provisional-cache-readd, r=compiler-errors
next solver: provisional cache

this adds the cache removed in #115843. However, it should now correctly track whether a provisional result depends on an inductive or coinductive stack.

While working on this, I was using the following doc: https://hackmd.io/VsQPjW3wSTGUSlmgwrDKOA. I don't think it's too helpful to understanding this, but am somewhat hopeful that the inline comments are more useful.

There are quite a few future perf improvements here. Given that this is already very involved I don't believe it is worth it (for now). While working on this PR one of my few attempts to significantly improve perf ended up being unsound again because I was not careful enough 

r? `@compiler-errors`
2024-01-12 07:04:42 +00:00