Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check xform_ret_ty for WF in the new solver to improve method winnowing #133519

Merged
merged 1 commit into from
Nov 28, 2024

Conversation

compiler-errors
Copy link
Member

@compiler-errors compiler-errors commented Nov 27, 2024

This is a bit interesting. Method probing in the old solver is stronger than the new solver because eagerly normalizing types causes us to check their corresponding trait goals. This is important because we don't end up checking all of the where clauses of a method when method probing; just the where clauses of the impl. i.e., for:

impl Foo
where
   WC1,
{
    fn method()
    where
        WC2,
    {}
}

We only check WC1 and not WC2. This is because at this point in probing the method is instantiated w/ infer vars, and checking the where clauses in WC2 will lead to cycles if we were to check them (at least that's my understanding; I could investigate changing that in general, incl. in the old solver, but I don't have much confidence that it won't lead to really bad overflows.)

This PR chooses to emulate the old solver by just checking that the return type is WF. This is theoretically stronger, but I'm not too worried about it. I think we alternatively have several approaches we can take here, though this one seems the simplest. Thoughts?

r? lcnr

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) labels Nov 27, 2024
@@ -0,0 +1,54 @@
//@ check-pass
Copy link
Contributor

@lcnr lcnr Nov 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please add a non-rustc test for this 🤔 or remove the extern type stuff from this one

@lcnr
Copy link
Contributor

lcnr commented Nov 27, 2024

we may want to chat about this in sync, I agree that there are a few ways to handle this. Relying on WF feels fairly straightforward and should closely match the old solver behavior 🤔 Can you add a test where we've got some struct W<T: Bound>(T) and an fn returning W<T>?

I feel like the 'correct' solution is to also check WC2 eagerly (given that we should always do so when existentially instantiating a binder). This is significantly? stronger and may cause issues with incomplete guidance and perf 🤔

I am fine with the current approach, so we can merge this as is, would like a fixme linking to a trait-system-refactor-initiative repo issue about this behavior

bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 27, 2024
[DO NOT MERGE] bootstrap with `-Znext-solver=globally`

A revival of rust-lang#124812.

Current status:

`./x.py b --stage 2` passes 🎉

### commits

- rust-lang#133501
- rust-lang#133493
- 9456bfe and b21b116 reimplement candidate preference based on rust-lang#132325, not yet a separate PR
- c3ef9cd is a rebased version of rust-lang#125334, unsure whether I actually want to land this PR for now
- rust-lang#133517
* rust-lang#133518
* rust-lang#133519
* rust-lang#133520
* rust-lang#133521
* rust-lang#133524

r? `@ghost`
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 27, 2024
[DO NOT MERGE] bootstrap with `-Znext-solver=globally`

A revival of rust-lang#124812.

Current status:

`./x.py b --stage 2` passes 🎉

### commits

- rust-lang#133501
- rust-lang#133493
- 9456bfe and b21b116 reimplement candidate preference based on rust-lang#132325, not yet a separate PR
- c3ef9cd is a rebased version of rust-lang#125334, unsure whether I actually want to land this PR for now
- rust-lang#133517
* rust-lang#133518
* rust-lang#133519
* rust-lang#133520
* rust-lang#133521
* rust-lang#133524

r? `@ghost`
@compiler-errors
Copy link
Member Author

@bors r=lcnr rollup

@bors
Copy link
Contributor

bors commented Nov 27, 2024

📌 Commit 4120fdb has been approved by lcnr

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 27, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 28, 2024
[DO NOT MERGE] bootstrap with `-Znext-solver=globally`

A revival of rust-lang#124812.

Current status:

`./x.py b --stage 2` passes 🎉

### commits

- rust-lang#133501
- rust-lang#133493
- 9456bfe and b21b116 reimplement candidate preference based on rust-lang#132325, not yet a separate PR
- c3ef9cd is a rebased version of rust-lang#125334, unsure whether I actually want to land this PR for now
- rust-lang#133517
* rust-lang#133518
* rust-lang#133519
* rust-lang#133520
* rust-lang#133521
* rust-lang#133524

r? `@ghost`
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 28, 2024
…llaumeGomez

Rollup of 12 pull requests

Successful merges:

 - rust-lang#129409 (Expand std::os::unix::fs::chown() doc with a warning)
 - rust-lang#133320 (Add release notes for Rust 1.83.0)
 - rust-lang#133368 (Delay a bug when encountering an impl with unconstrained generics in `codegen_select`)
 - rust-lang#133428 (Actually use placeholder regions for trait method late bound regions in `collect_return_position_impl_trait_in_trait_tys`)
 - rust-lang#133512 (Add `as_array` and `as_mut_array` conversion methods to slices.)
 - rust-lang#133519 (Check `xform_ret_ty` for WF in the new solver to improve method winnowing)
 - rust-lang#133520 (Structurally resolve before applying projection in borrowck)
 - rust-lang#133534 (extend group-forbid-always-trumps-cli test)
 - rust-lang#133537 ([rustdoc] Fix new clippy lints)
 - rust-lang#133543 ([AIX] create shim for lgammaf_r)
 - rust-lang#133547 (rustc_span: Replace a `HashMap<_, ()>` with `HashSet`)
 - rust-lang#133550 (print generated doc paths)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 06815d0 into rust-lang:master Nov 28, 2024
6 checks passed
@rustbot rustbot added this to the 1.85.0 milestone Nov 28, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Nov 28, 2024
Rollup merge of rust-lang#133519 - compiler-errors:xform-ret-wf, r=lcnr

Check `xform_ret_ty` for WF in the new solver to improve method winnowing

This is a bit interesting. Method probing in the old solver is stronger than the new solver because eagerly normalizing types causes us to check their corresponding trait goals. This is important because we don't end up checking all of the where clauses of a method when method probing; just the where clauses of the impl. i.e., for:

```
impl Foo
where
   WC1,
{
    fn method()
    where
        WC2,
    {}
}
```

We only check WC1 and not WC2. This is because at this point in probing the method is instantiated w/ infer vars, and checking the where clauses in WC2 will lead to cycles if we were to check them (at least that's my understanding; I could investigate changing that in general, incl. in the old solver, but I don't have much confidence that it won't lead to really bad overflows.)

This PR chooses to emulate the old solver by just checking that the return type is WF. This is theoretically stronger, but I'm not too worried about it. I think we alternatively have several approaches we can take here, though this one seems the simplest. Thoughts?

r? lcnr
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants