Commit Graph

1728 Commits

Author SHA1 Message Date
Michael Goulet
bf66723c0e Test and note unsafe ctor to fn ptr coercion
Also remove a note that I don't consider to be very useful in context.
2023-08-30 15:09:40 -07:00
Santiago Pastorino
b92840accf
Merge if and match expressions that don't make sense to have separated 2023-08-26 13:37:43 -03:00
Santiago Pastorino
e2efb6ab29
Check that universe can name other universe instead of equality 2023-08-25 18:14:00 -03:00
Santiago Pastorino
78da436cbb
Remove lub_empty from lexical region resolve 2023-08-25 17:16:08 -03:00
bors
a1e1dba9cc Auto merge of #114611 - nnethercote:type-system-chess, r=compiler-errors
Speed up compilation of `type-system-chess`

[`type-system-chess`](https://github.com/rust-lang/rustc-perf/pull/1680) is an unusual program that implements a compile-time chess position solver in the trait system(!)  This PR is about making it compile faster.

r? `@ghost`
2023-08-18 06:29:38 +00:00
Matthias Krüger
8db5a6d8ee
Rollup merge of #114819 - estebank:issue-78124, r=compiler-errors
Point at return type when it influences non-first `match` arm

When encountering code like

```rust
fn foo() -> i32 {
    match 0 {
        1 => return 0,
        2 => "",
        _ => 1,
    }
}
```

Point at the return type and not at the prior arm, as that arm has type `!` which isn't influencing the arm corresponding to arm `2`.

Fix #78124.
2023-08-15 20:34:25 +02:00
Matthias Krüger
d95cbece5e
Rollup merge of #114644 - compiler-errors:lt-err, r=wesleywiser
Point out expectation even if we have `TypeError::RegionsInsufficientlyPolymorphic`

just a minor tweak, since saying "one type is more general than the other" kinda sucks if we don't actually point out two types.
2023-08-15 20:34:24 +02:00
Esteban Küber
5021dde1a0 Move scrutinee HirId into MatchSource::TryDesugar 2023-08-14 21:43:56 +00:00
Esteban Küber
55f8c66a60 Point at return type when it influences non-first match arm
When encountering code like

```rust
fn foo() -> i32 {
    match 0 {
        1 => return 0,
        2 => "",
        _ => 1,
    }
}
```

Point at the return type and not at the prior arm, as that arm has type
`!` which isn't influencing the arm corresponding to arm `2`.

Fix #78124.
2023-08-14 21:43:56 +00:00
León Orell Valerian Liehr
1a18158891
Don't crash when reporting nice region errors for generic const items 2023-08-12 15:34:28 +02:00
Nicholas Nethercote
698f0e39e1 Ignore cause and recursion_depth in Obligation::{eq,hash}.
This gives massive (~7x) compile time and memory usage reductions for
the trait system stress test in
https://github.com/rust-lang/rustc-perf/pull/1680.
2023-08-09 15:38:00 +10:00
Michael Goulet
591b547e81 Point out expectation even if we have RegionsInsufficientlyPolymorphic 2023-08-09 01:10:08 +00:00
Matthias Krüger
3cd0a109a8
Rollup merge of #114566 - fmease:type-alias-laziness-is-crate-specific, r=oli-obk
Store the laziness of type aliases in their `DefKind`

Previously, we would treat paths referring to type aliases as *lazy* type aliases if the current crate had lazy type aliases enabled independently of whether the crate which the alias was defined in had the feature enabled or not.

With this PR, the laziness of a type alias depends on the crate it is defined in. This generally makes more sense to me especially if / once lazy type aliases become the default in a new edition and we need to think about *edition interoperability*:

Consider the hypothetical case where the dependency crate has an older edition (and thus eager type aliases), it exports a type alias with bounds & a where-clause (which are void but technically valid), the dependent crate has the latest edition (and thus lazy type aliases) and it uses that type alias. Arguably, the bounds should *not* be checked since at any time, the dependency crate should be allowed to change the bounds at will with a *non*-major version bump & without negatively affecting downstream crates.

As for the reverse case (dependency: lazy type aliases, dependent: eager type aliases), I guess it rules out anything from slight confusion to mild annoyance from upstream crate authors that would be caused by the compiler ignoring the bounds of their type aliases in downstream crates with older editions.

---

This fixes #114468 since before, my assumption that the type alias associated with a given weak projection was lazy (and therefore had its variances computed) did not necessarily hold in cross-crate scenarios (which [I kinda had a hunch about](https://github.com/rust-lang/rust/pull/114253#discussion_r1278608099)) as outlined above. Now it does hold.

`@rustbot` label F-lazy_type_alias
r? `@oli-obk`
2023-08-08 03:30:56 +02:00
León Orell Valerian Liehr
5468336d6b
Store the laziness of type aliases in the DefKind 2023-08-07 15:54:31 +02:00
Ali MJ Al-Nasrawy
2e83a72964 don't replace opaque types under binders with infer vars 2023-08-06 12:08:32 +00:00
Ali MJ Al-Nasrawy
d55522aad8 don't ICE on higher ranked hidden types 2023-08-04 15:11:09 +00:00
bors
4f7bb9890c Auto merge of #114036 - compiler-errors:upcast-to-fewer-assocs, r=lcnr
Rework upcasting confirmation to support upcasting to fewer projections in target bounds

This PR implements a modified trait upcasting algorithm that is resilient to changes in the number of associated types in the bounds of the source and target trait objects.

It does this by equating each bound of the target trait ref individually against the bounds of the source trait ref, rather than doing them all together by constructing a new trait object.

#### The new way we do trait upcasting confirmation

1. Equate the target trait object's principal trait ref with one of the supertraits of the source trait object's principal.
fdcab310b2/compiler/rustc_trait_selection/src/traits/select/mod.rs (L2509-L2525)

2. Make sure that every auto trait in the *target* trait object is present in the source trait ref's bounds.
fdcab310b2/compiler/rustc_trait_selection/src/traits/select/mod.rs (L2559-L2562)

3. For each projection in the *target* trait object, make sure there is exactly one projection that equates with it in the source trait ref's bound. If there is more than one, bail with ambiguity.
fdcab310b2/compiler/rustc_trait_selection/src/traits/select/mod.rs (L2526-L2557)
    * Since there may be more than one that applies, we probe first to check that there is exactly one, then we equate it outside of a probe once we know that it's unique.

4. Make sure the lifetime of the source trait object outlives the lifetime of the target.

<details>
<summary>Meanwhile, this is how we used to do upcasting:</summary>

1. For each supertrait of the source trait object, take that supertrait, append the source object's projection bounds, and the *target* trait object's auto trait bounds, and make this into a new object type:
d12c6e947c/compiler/rustc_trait_selection/src/traits/select/confirmation.rs (L915-L929)

2. Then equate it with the target trait object:
d12c6e947c/compiler/rustc_trait_selection/src/traits/select/confirmation.rs (L936)

This will be a type mismatch if the target trait object has fewer projection bounds, since we compare the bounds structurally in relate:
d12c6e947c/compiler/rustc_middle/src/ty/relate.rs (L696-L698)

</details>

Fixes #114035
Also fixes #114113, because I added a normalize call in the old solver.

r? types
2023-08-04 10:55:22 +00:00
Matthias Krüger
d6f714e44f
Rollup merge of #114355 - compiler-errors:resolve_vars_early, r=lcnr
resolve before canonicalization in new solver, ICE if unresolved

Fold the values with a resolver before canonicalization instead of making it happen within canonicalization.

This allows us to filter trivial region constraints from the external constraints.

r? ``@lcnr``
2023-08-04 09:18:59 +02:00
Michael Goulet
d87f4a6dc1 Placeholder nit 2023-08-03 20:05:40 +00:00
Michael Goulet
1bb6ae5874 Rework upcasting 2023-08-03 18:21:11 +00:00
bohan
2195fa6a9b fix the span in the suggestion of remove question mark 2023-08-03 16:44:02 +08:00
Deadbeef
4fec845c3f Remove constness from TraitPredicate 2023-08-02 15:38:00 +00:00
Nilstrieb
46f6b05eb7
Rollup merge of #114079 - compiler-errors:closure-upvars, r=oli-obk
Use `upvar_tys` in more places, make it return a list

Just a cleanup that fell out of a PR that I was gonna write, but that PR kinda got stuck.
2023-08-02 13:46:54 +02:00
Matthias Krüger
f338a1f7ee
Rollup merge of #114301 - compiler-errors:dont-error-on-missing-region-outlives, r=spastorino
Don't check unnecessarily that impl trait is RPIT

We have this random `return_type_impl_trait` function to detect if a function returns an RPIT which is used in outlives suggestions, but removing it doesn't actually change any diagnostics. Let's just remove it.

Also, suppress a spurious outlives error from a ReError.

Fixes #114274
2023-08-02 06:22:48 +02:00
Michael Goulet
99969d282b Use upvar_tys in more places, make it a list 2023-08-01 23:19:31 +00:00
Michael Goulet
1c35634efe Suppress unnecessary outlives 2023-08-01 17:16:47 +00:00
Michael Goulet
9295817bad Don't check unnecessarily that impl trait is RPIT 2023-07-31 18:13:48 +00:00
Matthias Krüger
692d764e53
Rollup merge of #114267 - compiler-errors:rpitit-opaque-bounds, r=spastorino
Map RPITIT's opaque type bounds back from projections to opaques

An RPITIT in a program's AST is eventually translated into both a projection GAT and an opaque. The opaque is used for default trait methods, like:

```
trait Foo {
  fn bar() -> impl Sized { 0i32 }
}
```

The item bounds for both the projection and opaque are identical, and both have a *projection* self ty. This is mostly okay, since we can normalize this projection within the default trait method body to the opaque, but it does two things:
1. it leads to bugs in places where we don't normalize item bounds, like `deduce_future_output_from_obligations`
2. it leads to extra match arms that are both suspicious looking and also easy to miss

This PR maps the opaque type bounds of the RPITIT's *opaque* back to the opaque's self type to avoid this quirk. Then we can fix the UI test for #108304 (1.) and also remove a bunch of match arms (2.).

Fixes #108304

r? `@spastorino`
2023-07-31 16:57:55 +02:00
Michael Goulet
44c8ab9f8b No need to expect RPITIT projections in opaque item bounds 2023-07-30 20:47:45 +00:00
Matthias Krüger
3ce90b1649 inline format!() args up to and including rustc_codegen_llvm 2023-07-30 14:22:50 +02:00
bors
ca1f813cc3 Auto merge of #114181 - matthiaskrgr:rollup-14m8s7f, r=matthiaskrgr
Rollup of 7 pull requests

Successful merges:

 - #114099 (privacy: no nominal visibility for assoc fns )
 - #114128 (When flushing delayed span bugs, write to the ICE dump file even if it doesn't exist)
 - #114138 (Adjust spans correctly for fn -> method suggestion)
 - #114146 (Skip reporting item name when checking RPITIT GAT's associated type bounds hold)
 - #114147 (Insert RPITITs that were shadowed by missing ADTs that resolve to [type error])
 - #114155 (Replace a lazy `RefCell<Option<T>>` with `OnceCell<T>`)
 - #114164 (Add regression test for `--cap-lints allow` and trait bounds warning)

r? `@ghost`
`@rustbot` modify labels: rollup
2023-07-28 23:53:12 +00:00
León Orell Valerian Liehr
9213aec762
Lower generic const items to HIR 2023-07-28 22:21:40 +02:00
Matthias Krüger
06eebbe6e7
Rollup merge of #114146 - compiler-errors:dont-report-rpitit-name, r=spastorino
Skip reporting item name when checking RPITIT GAT's associated type bounds hold

Doesn't really make sense to label an item that has a name that users can't really mention. Fixes #114145. Also fixes #113794.

r? `@spastorino`
2023-07-28 19:51:15 +02:00
Michael Goulet
0ae0643a53 Skip reporting item name when checking RPITIT GAT's associated type bounds hold 2023-07-27 22:09:44 +00:00
Deadbeef
e6b423aebb Remove constness from ParamEnv 2023-07-27 15:50:42 +00:00
Matthias Krüger
ed4c5fef72 fix some clippy::style findings
comparison_to_empty
iter_nth_zero
for_kv_map
manual_next_back
redundant_pattern
2023-07-23 23:36:56 +02:00
Matthias Krüger
b594798ae3 fix clippy::useless_format 2023-07-23 11:14:52 +02:00
Maybe Waffle
eabd306265 Document PredicateSet::insert
I always forget what the `bool` means :/
2023-07-19 09:44:40 +00:00
Michael Goulet
05f6890b3e Rename arg_iter to iter_instantiated 2023-07-17 21:04:12 +00:00
lcnr
19d46b690a self type param infer, avoid ICE 2023-07-16 15:29:08 +02:00
Mahdi Dibaiee
e55583c4b8 refactor(rustc_middle): Substs -> GenericArg 2023-07-14 13:27:35 +01:00
Mark Rousskov
cc907f80b9 Re-format let-else per rustfmt update 2023-07-12 21:49:27 -04:00
Jubilee
f7a34f9518
Rollup merge of #113567 - chenyukang:yukang-fix-113354-while-let, r=cjgillot
While let suggestion will work for closure body

Fixes #113354
2023-07-11 21:00:28 -07:00
bors
993deaa0bf Auto merge of #112984 - BoxyUwU:debug_with_infcx, r=compiler-errors
Introduce `trait DebugWithInfcx` to debug format types with universe info

Seeing universes of infer vars is valuable for debugging but currently we have no way of easily debug formatting a type with the universes of all the infer vars shown. In the future I hope to augment the new solver's proof tree output with a `DebugWithInfcx` impl so that it can show universes but I left that out of this PR as it would be non trivial and this is already large and complex enough.

The goal here is to make the various abstractions taking `T: Debug` able to use the codepath for printing out universes, that way we can do `debug!("{:?}", my_x)` and have `my_x` have universes shown, same for the `write!` macro. It's not possible to put the `Infcx: InferCtxtLike<I>` into the formatter argument to `Debug::fmt` so it has to go into the self ty. For this we introduce the type `OptWithInfcx<I: Interner, Infcx: InferCtxtLike<I>, T>` which has the data `T` optionally coupled with the infcx (more on why it's optional later).

Because of coherence/orphan rules it's not possible to write the impl `Debug for OptWithInfcx<..., MyType>` when `OptWithInfcx` is in a upstream crate. This necessitates a blanket impl in the crate defining `OptWithInfcx` like so: `impl<T: DebugWithInfcx> Debug for OptWithInfcx<..., T>`. It is not intended for people to manually call `DebugWithInfcx::fmt`, the `Debug` impl for `OptWithInfcx` should be preferred.

The infcx has to be optional in `OptWithInfcx` as otherwise we would end up with a large amount of code duplication. Almost all types that want to be used with `OptWithInfcx` do not themselves need access to the infcx so if we were to not optional we would end up with large `Debug` and `DebugWithInfcx` impls that were practically identical other than that when formatting their fields we wrap the field in `OptWithInfcx` instead of formatting it alone.

The only types that need access to the infcx themselves are ty/const/region infer vars, everything else is implemented by having the `Debug` impl defer to `OptWithInfcx` with no infcx available. The `DebugWithInfcx` impl is pretty much just the standard `Debug` impl except that instead of recursively formatting fields with `write!(f, "{x:?}")` we must do `write!(f, "{:?}", opt_infcx.wrap(x))`. This is some pretty rough boilerplate but I could not think of an alternative unfortunately.

`OptWithInfcx::wrap` is an eager `Option::map` because 99% of callsites were discarding the existing data in `OptWithInfcx` and did not need lazy evaluation.

A trait `InferCtxtLike` was added instead of using `InferCtxt<'tcx>` as we need to implement `DebugWithInfcx` for types living in `rustc_type_ir` which are generic over an interner and do not have access to `InferCtxt` since it lives in `rustc_infer`. Additionally I suspect that adding universe info to new solver proof tree output will require an implementation of `InferCtxtLike` for something that is not an `InferCtxt` although this is not the primary motivaton.

---

To summarize:
- There is a type `OptWithInfcx` which bundles some data optionally with an infcx with allows us to pass an infcx into a `Debug` impl. It's optional instead of being there unconditionally so that we can share code for `Debug` and `DebugWithInfcx` impls that don't care about whether there is an infcx available but have fields that might care.
- There is a trait `DebugWithInfcx` which allows downstream crates to add impls of the form `Debug for OptWithInfcx<...>` which would normally be forbidden by orphan rules/coherence.
- There is a trait `InferCtxtLike` to allow us to implement `DebugWithInfcx` for types that live in `rustc_type_ir`

This allows debug formatting various `ty::*` structures with universes shown by using the `Debug` impl for `OptWithInfcx::new(ty, infcx)`

---

This PR does not add `DebugWithInfcx` impls to absolutely _everything_ that should realistically have them, for example you cannot use `OptWithInfcx<Obligation<Predicate>>`. I am leaving this to a future PR to do so as it would likely be a lot more work to do.
2023-07-11 20:54:00 +00:00
Matthias Krüger
c6df564b8c
Rollup merge of #113310 - jieyouxu:dont-suggest-impl-trait-in-paths, r=lcnr
Don't suggest `impl Trait` in path position

Fixes #113264.
2023-07-11 17:46:18 +02:00
yukang
9aed9697cf While let suggestion will work for closure 2023-07-11 22:00:53 +08:00
bors
ce519c5945 Auto merge of #113474 - compiler-errors:rollup-07x1up7, r=compiler-errors
Rollup of 8 pull requests

Successful merges:

 - #113413 (Add needs-triage to all new issues)
 - #113426 (Don't ICE in `resolve_bound_vars` when associated return-type bounds are in bad positions)
 - #113427 (Remove `variances_of` on RPITIT GATs, remove its one use-case)
 - #113441 (miri: check that assignments do not self-overlap)
 - #113453 (Remove unused from_method from rustc_on_unimplemented)
 - #113456 (Avoid calling report_forbidden_specialization for RPITITs)
 - #113466 (Update cargo)
 - #113467 (Fix comment of `fn_can_unwind`)

r? `@ghost`
`@rustbot` modify labels: rollup
2023-07-08 10:46:29 +00:00
Michael Goulet
751dcaceb4
Rollup merge of #113427 - compiler-errors:no-variances-of-rpitit-gat, r=spastorino
Remove `variances_of` on RPITIT GATs, remove its one use-case

It doesn't make sense to implement variances on a GAT anyways, since we don't relate GATs with variance:

85bf07972a/compiler/rustc_middle/src/ty/relate.rs (L569-L579)

r? ``@spastorino``
2023-07-07 22:12:16 -07:00
bors
d4096e0412 Auto merge of #112652 - oli-obk:tait_only_in_sig, r=compiler-errors
Require TAITs to be mentioned in the signatures of functions that register hidden types for them

r? `@lcnr` `@compiler-errors`

This implements the lang team decision from [the TAIT design meeting](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/design.20meeting.202023-05-31.20TAITs/near/362518164).
2023-07-08 03:22:54 +00:00
许杰友 Jieyou Xu (Joe)
b5208b3611
Don't suggest impl Trait in path position 2023-07-08 00:04:33 +08:00