Commit Graph

2775 Commits

Author SHA1 Message Date
Michael Goulet
db235a07f7 Remove unnecessary call to select_from_obligation
The only regression is one ambiguity in the new trait solver, having to
do with two param-env candidates that may apply. I think this is fine,
since the error message already kinda sucks.
2023-06-20 23:33:02 +00:00
bors
46514218f6 Auto merge of #112835 - lcnr:proof-tree-nits, r=BoxyUwU
proof tree nits

r? `@BoxyUwU`
2023-06-20 19:58:46 +00:00
lcnr
e4b171a198 inspect nits 2023-06-20 14:01:03 +02:00
lcnr
f7472aa69e cleanup imports 2023-06-20 12:41:00 +02:00
lcnr
f5438d658f split probe into 2 functions for better readability 2023-06-20 12:40:43 +02:00
bors
6fc0273b5a Auto merge of #112320 - compiler-errors:do-not-impl-via-obj, r=lcnr
Add `implement_via_object` to `rustc_deny_explicit_impl` to control object candidate assembly

Some built-in traits are special, since they are used to prove facts about the program that are important for later phases of compilation such as codegen and CTFE. For example, the `Unsize` trait is used to assert to the compiler that we are able to unsize a type into another type. It doesn't have any methods because it doesn't actually *instruct* the compiler how to do this unsizing, but this is later used (alongside an exhaustive match of combinations of unsizeable types) during codegen to generate unsize coercion code.

Due to this, these built-in traits are incompatible with the type erasure provided by object types. For example, the existence of `dyn Unsize<T>` does not mean that the compiler is able to unsize `Box<dyn Unsize<T>>` into `Box<T>`, since `Unsize` is a *witness* to the fact that a type can be unsized, and it doesn't actually encode that unsizing operation in its vtable as mentioned above.

The old trait solver gets around this fact by having complex control flow that never considers object bounds for certain built-in traits:
2f896da247/compiler/rustc_trait_selection/src/traits/select/candidate_assembly.rs (L61-L132)

However, candidate assembly in the new solver is much more lovely, and I'd hate to add this list of opt-out cases into the new solver. Instead of maintaining this complex and hard-coded control flow, instead we can make this a property of the trait via a built-in attribute. We already have such a build attribute that's applied to every single trait that we care about: `rustc_deny_explicit_impl`. This PR adds `implement_via_object` as a meta-item to that attribute that allows us to opt a trait out of object-bound candidate assembly as well.

r? `@lcnr`
2023-06-20 08:42:37 +00:00
Michael Goulet
ca68cf0d46 Merge attrs, better validation 2023-06-20 04:38:55 +00:00
Michael Goulet
657d3f43a9 Add rustc_do_not_implement_via_object 2023-06-20 04:38:46 +00:00
Michael Goulet
3171c989ef
Rollup merge of #112781 - compiler-errors:new-solver-tait-overlaps-hidden, r=lcnr
Don't consider TAIT normalizable to hidden ty if it would result in impossible item bounds

See test for example where we shouldn't consider it possible to alias-relate a TAIT and hidden type.

r? `@lcnr`
2023-06-19 17:53:35 -07:00
Matthias Krüger
68d3e0e3bd
Rollup merge of #112783 - compiler-errors:nlb-fnptr-reject-ice, r=fee1-dead
Don't ICE on bound var in `reject_fn_ptr_impls`

We may try to use an impl like `impl<T: FnPtr> PartialEq {}` to satisfy a predicate like `for<T> T: PartialEq` -- don't ICE in that case.

Fixes #112735
2023-06-19 19:26:28 +02:00
Matthias Krüger
68f2f1e32c
Rollup merge of #112777 - compiler-errors:normalize-weak-more, r=oli-obk
Continue folding in query normalizer on weak aliases

Fixes #112752
Fixes #112731 (same root cause, so didn't make a test for it)
fixes #112776

r? ```@oli-obk```
2023-06-19 19:26:27 +02:00
Michael Goulet
2e8af07a8a Don't consider TAIT normalizable to hidden ty if it would result in impossible item bounds 2023-06-19 14:49:56 +00:00
Boxy
9af7122b1d create module so that RUSTC_LOG can filter to just proof trees 2023-06-19 09:08:03 +01:00
Boxy
bb743f8635 allow caller to force proof tree generation 2023-06-19 09:08:03 +01:00
Boxy
51090b962f show normalizes-to hack and response instantiation goals 2023-06-19 09:06:16 +01:00
Boxy
e367c04dc6 introduce a separate set of types for finalized proof trees 2023-06-19 09:06:16 +01:00
Boxy
7a3665d016 dont use a trait 2023-06-19 09:01:37 +01:00
Boxy
3587d4ced8 say what kind of cache hit 2023-06-19 09:01:37 +01:00
Boxy
a2050ba12d add -Z flag 2023-06-19 09:01:37 +01:00
Boxy
3009b2c647 initial info dump 2023-06-19 09:01:37 +01:00
Michael Goulet
29c74d5619 Don't ICE on bound var in reject_fn_ptr_impls 2023-06-19 02:52:03 +00:00
Michael Goulet
493b18b653 Continue folding in query normalizer on weak aliases 2023-06-18 20:56:30 +00:00
Michael Goulet
6594c75449 Move ConstEvaluatable to Clause 2023-06-17 21:27:13 +00:00
Michael Goulet
52d3fc93f2 Move WF goal to clause 2023-06-17 21:20:20 +00:00
Michael Goulet
d97d4ebecc Remove even more redundant builtin candidates 2023-06-17 03:32:46 +00:00
Michael Goulet
2835d9d1d3 Simplify even more candidates 2023-06-17 03:32:46 +00:00
Michael Goulet
1311bb56f3 Simplify an ObjectData field 2023-06-17 03:32:45 +00:00
Michael Goulet
9e68b6f505 Simplify some impl source candidates 2023-06-17 03:32:45 +00:00
Michael Goulet
1704481bfa Remove some ImplSource candidates 2023-06-17 03:32:45 +00:00
bors
0cc541e4b2 Auto merge of #108860 - oli-obk:tait_alias, r=compiler-errors
Add `AliasKind::Weak` for type aliases.

`type Foo<T: Debug> = Bar<T>;` does not check `T: Debug` at use sites of `Foo<NotDebug>`, because in contrast to a

```rust
trait Identity {
    type Identity;
}
impl<T: Debug> Identity for T {
    type Identity = T;
}
<NotDebug as Identity>::Identity
```

type aliases do not exist in the type system, but are expanded to their aliased type immediately when going from HIR to the type layer.

Similarly:

* a private type alias for a public type is a completely fine thing, even though it makes it a bit hard to write out complex times sometimes
* rustdoc expands the type alias, even though often times users use them for documentation purposes
* diagnostics show the expanded type, which is confusing if the user wrote a type alias and the diagnostic talks about another type that they don't know about.

For type alias impl trait, these issues do not actually apply in most cases, but sometimes you have a type alias impl trait like `type Foo<T: Debug> = (impl Debug, Bar<T>);`, which only really checks it for `impl Debug`, but by accident prevents `Bar<T>` from only being instantiated after proving `T: Debug`. This PR makes sure that we always check these bounds explicitly and don't rely on an implementation accident.

To not break all the type aliases out there, we only use it when the type alias contains an opaque type. We can decide to do this for all type aliases over an edition.

Or we can later extend this to more types if we figure out the back-compat concerns with suddenly checking such bounds.

As a side effect, easily allows fixing https://github.com/rust-lang/rust/issues/108617, which I did.

fixes https://github.com/rust-lang/rust/issues/108617
2023-06-17 00:33:29 +00:00
Michael Goulet
cef94ecedf
Rollup merge of #112665 - compiler-errors:assumption-takes-clause, r=lcnr
Make assumption functions in new solver take `Binder<'tcx, Clause<'tcx>>`

We just use an if-let to match on an optional clause at all the places where we transition from `Predicate` -> `Clause`, but I assume that when things like item-bounds and param-env start to only store `Clause`s then those can just be trivially dropped.

r? ``@lcnr``
2023-06-16 12:53:23 -07:00
Oli Scherer
f3b7dd6388 Add AliasKind::Weak for type aliases.
Only use it when the type alias contains an opaque type.

Also does wf-checking on such type aliases.
2023-06-16 19:39:48 +00:00
Dylan DPC
64f6c00772
Rollup merge of #112443 - compiler-errors:next-solver-opportunistically-resolve-regions, r=lcnr
Opportunistically resolve regions in new solver

Use `opportunistic_resolve_var` during canonicalization to collapse some regions.

We have to start using `CanonicalVarValues::is_identity_modulo_regions`. We also have to modify that function to consider responses like `['static, ^0, '^1, ^2]` to be an "identity" response, since because we opportunistically resolve regions, there's no longer a 1:1 mapping between canonical var values and bound var indices in the response...

There's one nasty side-effect -- one test (`tests/ui/dyn-star/param-env-infer.rs`) starts to ICE because the certainty goes from `Yes` to `Maybe(Overflow)`... Not exactly sure why, though? Putting this up for discussion/investigation.

r? ```@lcnr```
2023-06-16 14:46:15 +05:30
bohan
b7921981d5 fix: inline predicate_may_hold_fatal 2023-06-16 11:09:53 +08:00
Michael Goulet
b4ba7c4f93 Make assumption functions in new solver take clause 2023-06-15 16:18:38 +00:00
bors
6ee4265ca6 Auto merge of #104455 - the8472:dont-drain-on-drop, r=Amanieu
Don't drain-on-drop in DrainFilter impls of various collections.

This removes drain-on-drop behavior from various unstable DrainFilter impls (not yet for HashSet/Map) because that behavior [is problematic](https://github.com/rust-lang/rust/issues/43244#issuecomment-641638196) (because it can lead to panic-in-drop when user closures panic) and may become forbidden if [this draft RFC passes](https://github.com/rust-lang/rfcs/pull/3288).

closes #101122

[ACP](https://github.com/rust-lang/libs-team/issues/136)

affected tracking issues
* #43244
* #70530
* #59618

Related hashbrown update: https://github.com/rust-lang/hashbrown/pull/374
2023-06-15 00:03:10 +00:00
Matthias Krüger
7240943b28
Rollup merge of #112605 - compiler-errors:negative-docs, r=spastorino
Improve docs/clean up negative overlap functions

Clean up some functions in ways that should not affect behavior, change some names to be clearer (`negative_impl` and `implicit_negative` are not really clear imo), and add some documentation examples.

r? `@spastorino`
2023-06-14 18:10:30 +02:00
bors
7b0eac438a Auto merge of #112400 - WaffleLapkin:vtable_stats, r=compiler-errors
Collect VTable stats & add `-Zprint-vtable-sizes`

This is a bit hacky/buggy, but I'm not entirely sure how to fix it, so I want to ask reviewers for help...

To try this, use either of those:
- `cargo clean && RUSTFLAGS="-Zprint-vtable-sizes" cargo +toolchain b`
- `cargo clean && cargo rustc +toolchain -Zprint-vtable-sizes`
- `rustc +toolchain -Zprint-vtable-sizes ./file.rs`
2023-06-14 11:24:42 +00:00
bors
3ed2a10d17 Auto merge of #110662 - bryangarza:safe-transmute-reference-types, r=compiler-errors
Safe Transmute: Enable handling references

This patch enables support for references in Safe Transmute, by generating nested obligations during trait selection. Specifically, when we call `confirm_transmutability_candidate(...)`, we now recursively traverse the `rustc_transmute::Answer` tree and create obligations for all the `Answer` variants, some of which include multiple nested `Answer`s.
2023-06-14 08:26:22 +00:00
The 8472
18c9a12d13 remove hash_drain_filter feature uses 2023-06-14 09:28:56 +02:00
The 8472
114d5f221c s/drain_filter/extract_if/ for Vec, Btree{Map,Set} and LinkedList 2023-06-14 09:28:54 +02:00
The 8472
c0df1c8c43 remove drain-on-drop behavior from vec::DrainFilter and add #[must_use] 2023-06-14 09:24:51 +02:00
Michael Goulet
9e210522bc Improve docs/clean up negative overlap functions 2023-06-14 02:18:30 +00:00
Michael Goulet
01377e8064 opportunistically resolve regions 2023-06-13 22:10:51 +00:00
Matthias Krüger
b7706e891d
Rollup merge of #111885 - compiler-errors:rust-call-abi-sized, r=eholk
Don't ICE on unsized `extern "rust-call"` call

Conceptually builds on #111864, but doesn't depend on it.
2023-06-13 07:02:28 +02:00
Bryan Garza
f4cf8f65a5 Safe Transmute: Refactor error handling and Answer type
- Create `Answer` type that is not just a type alias of `Result`
- Remove a usage of `map_layouts` to make the code easier to read
- Don't hide errors related to Unknown Layout when computing transmutability
2023-06-12 16:56:21 -07:00
Maybe Waffle
f2545fb225 Collect VTable stats & add -Zprint-vtable-sizes 2023-06-12 15:58:35 +00:00
lcnr
e74d1cd581 update comment 2023-06-12 12:47:09 +02:00
bors
34d64ab7a2 Auto merge of #112466 - lcnr:opaque-type-cleanup, r=compiler-errors
opaque type cleanup

the commits are pretty self-contained.

r? `@compiler-errors` cc `@oli-obk`
2023-06-11 03:42:14 +00:00
lcnr
b62e20d2fd split opaque type handling in new solver
be more explicit in where we only add new hidden types
and where we also have to deal with item bounds.
2023-06-09 16:41:11 +02:00