-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
support revealing defined opaque post borrowck #133501
Conversation
Some changes occurred to the core trait solver cc @rust-lang/initiative-trait-system-refactor |
9e42ad1
to
3bc801d
Compare
[DO NOT MERGE] bootstrap with `-Znext-solver=globally` A revival of rust-lang#124812. Current status, we're failing in: - failing in `rustc_next_trait_solver` with 126 instances of the following error ``` error[E0311]: the parameter type `I` may not live long enough | help: consider adding an explicit lifetime bound --> compiler/rustc_next_trait_solver/src/solve/trait_goals.rs:624:53 | 624 ~ fn consider_structural_builtin_unsize_candidates<'a>( 625 ~ ecx: &mut EvalCtxt<'a, D>, 626 | goal: Goal<I, Self>, 627 ~ ) -> Vec<Candidate<I>> where I: 'a { ``` - `itertools` hangs, we're already encountered this hang in our previous attempt due to large type sizes. I believe that it's simply caused by a missing cache somewhere, potentially in `wf.rs`, but other visitors may also be responsible. See rust-itertools/itertools#945 for more details ### 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 r? `@ghost`
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally happy w/ the approach. I like how small the diff is given the typing mode refactor :D
Could you try to uplift fold_regions
? It feels bad to have that not be a folder defined in type_ir since it's really pretty simple otherwise.
3bc801d
to
a35cda9
Compare
HIR ty lowering was modified cc @fmease |
a35cda9
to
299b742
Compare
rdy |
[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`
This comment has been minimized.
This comment has been minimized.
[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`
[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`
299b742
to
34a8c2d
Compare
actually rdy xd |
@bors r+ |
…piler-errors support revealing defined opaque post borrowck By adding a new `TypingMode::PostBorrowckAnalysis`. Currently only supported with the new solver and I didn't look into the way we replace `ReErased`. `@compiler-errors` mentioned that always using existentials may be unsound. r? `@compiler-errors`
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#132782 (improvements on initial sysroot and libdir finding logics) - rust-lang#133134 (Don't use a SyntheticProvider for literally every type) - rust-lang#133466 (Fix typos in pin.rs) - rust-lang#133492 (bootstrap: allow skipping steps with start of path) - rust-lang#133501 (support revealing defined opaque post borrowck) - rust-lang#133530 (Use consistent wording in docs, use is zero instead of is 0) - rust-lang#133538 (Better diagnostic for fn items in variadic functions) - rust-lang#133590 (Rename `-Zparse-only`) r? `@ghost` `@rustbot` modify labels: rollup
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#132782 (improvements on initial sysroot and libdir finding logics) - rust-lang#133466 (Fix typos in pin.rs) - rust-lang#133492 (bootstrap: allow skipping steps with start of path) - rust-lang#133501 (support revealing defined opaque post borrowck) - rust-lang#133530 (Use consistent wording in docs, use is zero instead of is 0) - rust-lang#133538 (Better diagnostic for fn items in variadic functions) - rust-lang#133590 (Rename `-Zparse-only`) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#133501 - lcnr:post-borrowck-analysis, r=compiler-errors support revealing defined opaque post borrowck By adding a new `TypingMode::PostBorrowckAnalysis`. Currently only supported with the new solver and I didn't look into the way we replace `ReErased`. ``@compiler-errors`` mentioned that always using existentials may be unsound. r? ``@compiler-errors``
By adding a new
TypingMode::PostBorrowckAnalysis
. Currently only supported with the new solver and I didn't look into the way we replaceReErased
. @compiler-errors mentioned that always using existentials may be unsound.Checking that opaque types are well-formed has to be able to reveal other opaque types defined by the same scope. We previously did not properly support this and instead simply allowed
check_opaque_meets_bounds
to define these opaques again, and then checked that the resulting constraints match the hidden types of the defining function. This results in ambiguity errors when trying to normalize such an opaque without actually defining it. See https://github.com/rust-lang/rust/blob/master/tests/ui/traits/next-solver/opaques/no-define-in-wf-check.rs for examples.r? @compiler-errors