Commit Graph

508 Commits

Author SHA1 Message Date
bors
b656f5171b Auto merge of #119338 - compiler-errors:upcast-plus-autos, r=lcnr
Consider principal trait ref's auto-trait super-traits in dyn upcasting

Given traits like:

```rust
trait Subtrait: Supertrait + Send {}
trait Supertrait {}
```

We should be able to upcast `dyn Subtrait` to `dyn Supertrait + Send`. This is not currently possible, because when upcasting, we look at the list of auto traits in the object type (`dyn Subtrait`, which has no auto traits in its bounds) and compare them to the target's auto traits (`dyn Supertrait + Send`, which has `Send` in its bound).

Since the target has auto traits that are not present in the source, the upcasting fails. This is overly restrictive, since `dyn Subtrait` will always implement `Send` via its built-in object impl. I propose to loosen this restriction here.

r? types

---

### ~~Aside: Fix this in astconv instead?~~

### edit: This causes too many failures. See https://github.com/rust-lang/rust/pull/119825#issuecomment-1890847150

We may also fix this by by automatically elaborating all auto-trait supertraits during `AstConv::conv_object_ty_poly_trait_ref`. That is, we can make it so that `dyn Subtrait` is elaborated into the same type of `dyn Subtrait + Send`.

I'm open to considering this solution instead, but it would break coherence in the following example:

```rust
trait Foo: Send {}

trait Bar {}
impl Bar for dyn Foo {}
impl Bar for dyn Foo + Send {}
//~^ This would begin to be an overlapping impl.
```
2024-02-15 19:16:06 +00:00
Michael Goulet
ec8e898193 Consider principal trait ref's auto-trait super-traits in dyn upcasting 2024-02-15 15:38:11 +00:00
Oli Scherer
c1bb352c8b Continue compilation even if inherent impl checks fail 2024-02-14 21:04:51 +00:00
bors
ee9c7c940c Auto merge of #120847 - oli-obk:track_errors9, r=compiler-errors
Continue compilation after check_mod_type_wf errors

The ICEs fixed here were probably reachable through const eval gymnastics before, but now they are easily reachable without that, too.

The new errors are often bugfixes, where useful errors were missing, because they were reported after the early abort. In other cases sometimes they are just duplication of already emitted errors, which won't be user-visible due to deduplication.

fixes https://github.com/rust-lang/rust/issues/120860
2024-02-14 18:32:19 +00:00
Guillaume Gomez
b36e094802
Rollup merge of #120893 - c410-f3r:testsssssss, r=petrochenkov
Move some tests

r? `@petrochenkov`
2024-02-14 15:41:26 +01:00
Oli Scherer
5f6390f947 Continue compilation after check_mod_type_wf errors 2024-02-14 11:00:30 +00:00
Oli Scherer
9e31121985
Rollup merge of #121049 - estebank:issue-121009, r=fmease
Do not point at `#[allow(_)]` as the reason for compat lint triggering

Fix #121009.
2024-02-14 11:53:42 +01:00
Oli Scherer
f3e66edd63
Rollup merge of #120915 - OdenShirataki:master, r=fmease
Fix suggestion span for `?Sized` when param type has default

Fixes #120878

Diagnostic suggests adding `: ?Sized` in an incorrect place if a type parameter default is present

r? `@fmease`
2024-02-14 11:53:39 +01:00
Oli Scherer
c4371a79de
Rollup merge of #120530 - trevyn:issue-116434, r=compiler-errors
Be less confident when `dyn` suggestion is not checked for object safety

#120275 no longer checks bare traits for object safety when making a `dyn` suggestion on Rust < 2021. In this case, qualify the suggestion with a note that the trait must be object safe, to prevent user confusion as seen in #116434

r? ```@fmease```
2024-02-14 11:53:39 +01:00
Caio
0e9aa75bcd Move tests 2024-02-13 18:08:25 -03:00
Esteban Küber
24b52fd9df Do not point at #[allow(_)] as the reason for compat lint triggering
Fix #121009.
2024-02-13 20:27:43 +00:00
lcnr
3e3e207ad7 use alias-relate to structurally normalize in the solver 2024-02-13 05:08:51 +01:00
OdenShirataki
4ac90e286b Fix suggestion span for ?Sized
when param type has default
and type in trait is generic.
2024-02-12 11:33:11 +09:00
trevyn
29fd82b24e Be less confident when dyn suggestion is not checked for object safety 2024-02-09 20:47:50 -08:00
Matthias Krüger
34489b7769
Rollup merge of #120629 - c410-f3r:testsssssss, r=petrochenkov
Move some test files

r? ``@petrochenkov``
2024-02-10 00:58:38 +01:00
Caio
69a5264a52 Move some tests 2024-02-09 15:43:08 -03:00
Matthias Krüger
251584581f
Rollup merge of #120836 - lcnr:param-env-hide-impl, r=BoxyUwU
hide impls if trait bound is proven from env

AVERT YOUR EYES `@compiler-errors`

fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/76 and https://github.com/rust-lang/trait-system-refactor-initiative/issues/12#issuecomment-1865234925

this is kinda ugly and I hate it, but I wasn't able to think of a cleaner approach for now. I am also unsure whether we have to refine this filtering later on, so by making the change pretty minimal it should be easier to improve going forward.

r? `@BoxyUwU`
2024-02-09 19:21:19 +01:00
Matthias Krüger
99bafad6c2
Rollup merge of #120354 - lukas-code:metadata-normalize, r=lcnr
improve normalization of `Pointee::Metadata`

This PR makes it so that `<Wrapper<Tail> as Pointee>::Metadata` is normalized to `<Tail as Pointee>::Metadata` if we don't know `Wrapper<Tail>: Sized`. With that, the trait solver can prove projection predicates like `<Wrapper<Tail> as Pointee>::Metadata == <Tail as Pointee>::Metadata`, which makes it possible to use the metadata APIs to cast between the tail and the wrapper:

```rust
#![feature(ptr_metadata)]

use std::ptr::{self, Pointee};

fn cast_same_meta<T: ?Sized, U: ?Sized>(ptr: *const T) -> *const U
where
    T: Pointee<Metadata = <U as Pointee>::Metadata>,
{
    let (thin, meta) = ptr.to_raw_parts();
    ptr::from_raw_parts(thin, meta)
}

struct Wrapper<T: ?Sized>(T);

fn cast_to_wrapper<T: ?Sized>(ptr: *const T) -> *const Wrapper<T> {
    cast_same_meta(ptr)
}
```

Previously, this failed to compile:

```
error[E0271]: type mismatch resolving `<Wrapper<T> as Pointee>::Metadata == <T as Pointee>::Metadata`
  --> src/lib.rs:16:5
   |
15 | fn cast_to_wrapper<T: ?Sized>(ptr: *const T) -> *const Wrapper<T> {
   |                    - found this type parameter
16 |     cast_same_meta(ptr)
   |     ^^^^^^^^^^^^^^ expected `Wrapper<T>`, found type parameter `T`
   |
   = note: expected associated type `<Wrapper<T> as Pointee>::Metadata`
              found associated type `<T as Pointee>::Metadata`
   = note: an associated type was expected, but a different one was found
```

(Yes, you can already do this with `as` casts. But using functions is so much  *safer* , because you can't change the metadata on accident.)

---

This PR essentially changes the built-in impls of `Pointee` from this:

```rust
// before

impl Pointee for u8 {
    type Metadata = ();
}

impl Pointee for [u8] {
    type Metadata = usize;
}

// ...

impl Pointee for Wrapper<u8> {
    type Metadata = ();
}

impl Pointee for Wrapper<[u8]> {
    type Metadata = usize;
}

// ...

// This impl is only selected if `T` is a type parameter or unnormalizable projection or opaque type.
fallback impl<T: ?Sized> Pointee for Wrapper<T>
where
    Wrapper<T>: Sized
{
    type Metadata = ();
}

// This impl is only selected if `T` is a type parameter or unnormalizable projection or opaque type.
fallback impl<T /*: Sized */> Pointee for T {
    type Metadata = ();
}
```

to this:

```rust
// after

impl Pointee for u8 {
    type Metadata = ();
}

impl Pointee for [u8] {
    type Metadata = usize;
}

// ...

impl<T: ?Sized> Pointee for Wrapper<T> {
    // in the old solver this will instead project to the "deep" tail directly,
    // e.g. `Wrapper<Wrapper<T>>::Metadata = T::Metadata`
    type Metadata = <T as Pointee>::Metadata;
}

// ...

// This impl is only selected if `T` is a type parameter or unnormalizable projection or opaque type.
fallback impl<T /*: Sized */> Pointee for T {
    type Metadata = ();
}
```
2024-02-09 19:21:16 +01:00
lcnr
5051637979 hide impls if trait bound is proven from env 2024-02-09 12:41:39 +01:00
bors
1280928a99 Auto merge of #120767 - matthiaskrgr:rollup-0k8ib1c, r=matthiaskrgr
Rollup of 9 pull requests

Successful merges:

 - #119592 (resolve: Unload speculatively resolved crates before freezing cstore)
 - #120103 (Make it so that async-fn-in-trait is compatible with a concrete future in implementation)
 - #120206 (hir: Make sure all `HirId`s have corresponding HIR `Node`s)
 - #120214 (match lowering: consistently lower bindings deepest-first)
 - #120688 (GVN: also turn moves into copies with projections)
 - #120702 (docs: also check the inline stmt during redundant link check)
 - #120727 (exhaustiveness: Prefer "`0..MAX` not covered" to "`_` not covered")
 - #120734 (Add `SubdiagnosticMessageOp` as a trait alias.)
 - #120739 (improve pretty printing for associated items in trait objects)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-02-08 12:14:19 +00:00
Oli Scherer
eab2adb660 Continue to borrowck even if there were previous errors 2024-02-08 08:10:43 +00:00
Matthias Krüger
a059dd88bf
Rollup merge of #120739 - lukas-code:pp-dyn-assoc, r=compiler-errors
improve pretty printing for associated items in trait objects

* Don't print a binder in front of associated items, because it's not valid syntax.
  * e.g. print `dyn for<'a> Trait<'a, Assoc = &'a u8>` instead of `dyn for<'a> Trait<'a, for<'a> Assoc = &'a u8>`.
* Don't print associated items that are implied by a supertrait bound.
  * e.g. if we have `trait Sub: Super<Assoc = u8> {}`, then just print `dyn Sub` instead of `dyn Sub<Assoc = u8>`.

I've added the test in the first commit, so you can see the diff of the compiler output in the second commit.
2024-02-08 09:06:36 +01:00
bors
870a01a30e Auto merge of #120558 - oli-obk:missing_impl_item_ice, r=estebank
Stop bailing out from compilation just because there were incoherent traits

fixes #120343

but also has a lot of "type annotations needed" fallout. Some are fixed in the second commit.
2024-02-08 05:01:09 +00:00
Lukas Markeffsky
c636c7ae2c address review comments and add more tests 2024-02-07 20:58:05 +01:00
Lukas Markeffsky
18e5bbfad6 improve pretty printing for trait objects 2024-02-07 16:09:46 +01:00
Lukas Markeffsky
fd9202109b add test for pretty printing trait objects 2024-02-07 12:51:31 +01:00
r0cky
c7519d42c2 Update tests 2024-02-07 10:42:01 +08:00
Matthias Krüger
012ce8ae98
Rollup merge of #120513 - compiler-errors:normalize-regions-for-nll, r=lcnr
Normalize type outlives obligations in NLL for new solver

Normalize the type outlives assumptions and obligations in MIR borrowck. This should fix any of the lazy-norm-related MIR borrowck problems.

Also some cleanups from last PR:
1. Normalize obligations in a loop in lexical region resolution
2. Use `deeply_normalize_with_skipped_universes` in lexical resolution since we may have, e.g. `for<'a> Alias<'a>: 'b`.

r? lcnr
2024-02-06 22:45:43 +01:00
Matthias Krüger
af99946700
Rollup merge of #120507 - estebank:issue-108428, r=davidtwco
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.

Follow up to #120396, only last commit is relevant.
2024-02-06 22:45:42 +01:00
Matthias Krüger
a0c3b87823
Rollup merge of #120396 - estebank:method-on-unbounded-type-param, r=nnethercote
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-02-06 22:45:40 +01:00
Lukas Markeffsky
42cc1d2f97 new solver: improve normalization of Pointee::Metadata 2024-02-05 15:58:46 +01:00
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
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