-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Remove DefiningAnchor from InferCtxt #108389
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @lcnr (or someone else) soon. Please see the contribution instructions for more information. |
Some changes occurred in engine.rs, potentially modifying the public API of Some changes occurred to the core trait solver cc @rust-lang/initiative-trait-system-refactor |
@bors try @rust-timer queue need to crater this, too |
This comment has been minimized.
This comment has been minimized.
⌛ Trying commit c6f51440db29e048884073c7767841e88a8c9275 with merge f8af1895d636b112468fb6304c316e2cce25a8d6... |
💔 Test failed - checks-actions |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
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.
I really like this change.
I personally think it would be good to stop using DefiningAnchor::Error
as the default and always require the user to explicitly provide the anchor.
E.g. by changing infcx.at(param_env, cause).define_opaque_types(anchor)
to infcx.at(param_env, cause, anchor)
.
Same for ObligationCtxt
and probably a few other places.
having looked through all changes yet, but I am really happy about what I've seen so far and the general direction of this PR.
yea, but doing that at the same time as this PR would've been increadibly hard to review properly |
c6f5144
to
557cf7b
Compare
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
⌛ Trying commit 557cf7bf1aea5ccdaa663a66cc254fe6d5c5d405 with merge 9edc8987ad42f7a9d21d57465015000ae3578c17... |
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Some changes occurred in cc @BoxyUwU Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
@craterbot check |
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
It was only used in error paths or places already using `DefiningAchor::Error` already
They were already `Error` at all use sites
…assing it in every time
The job Click to see the possible cause of the failure (guessed by this bot)
|
☔ The latest upstream changes (presumably #108707) made this pull request unmergeable. Please resolve the merge conflicts. |
@lcnr is working on doing something similar to this PR in smaller steps. |
… r=oli-obk make `define_opaque_types` fully explicit based on the idea of rust-lang#108389. Moved `define_opaque_types` into the actual operations, e.g. `eq`, instead of `infcx.at` because normalization doesn't use `define_opaque_types` and even creates it's own `At` with a different `define_opaque_types` internally. Somewhat surprisingly, coherence actually relies on `DefineOpaqueTypes::Yes` for soundness which was revealed because I've incorrectly used `DefineOpaqueTypes::No` in `equate_impl_headers`. It feels concerning that even though this is the case, we still sometimes use `DefineOpaqueTypes::No` in coherence. I did not look into this as part of this PR as it is purely changing the structure of the code without changing behavior in any way. r? `@oli-obk`
… r=oli-obk make `define_opaque_types` fully explicit based on the idea of rust-lang#108389. Moved `define_opaque_types` into the actual operations, e.g. `eq`, instead of `infcx.at` because normalization doesn't use `define_opaque_types` and even creates it's own `At` with a different `define_opaque_types` internally. Somewhat surprisingly, coherence actually relies on `DefineOpaqueTypes::Yes` for soundness which was revealed because I've incorrectly used `DefineOpaqueTypes::No` in `equate_impl_headers`. It feels concerning that even though this is the case, we still sometimes use `DefineOpaqueTypes::No` in coherence. I did not look into this as part of this PR as it is purely changing the structure of the code without changing behavior in any way. r? ``@oli-obk``
… r=oli-obk make `define_opaque_types` fully explicit based on the idea of rust-lang#108389. Moved `define_opaque_types` into the actual operations, e.g. `eq`, instead of `infcx.at` because normalization doesn't use `define_opaque_types` and even creates it's own `At` with a different `define_opaque_types` internally. Somewhat surprisingly, coherence actually relies on `DefineOpaqueTypes::Yes` for soundness which was revealed because I've incorrectly used `DefineOpaqueTypes::No` in `equate_impl_headers`. It feels concerning that even though this is the case, we still sometimes use `DefineOpaqueTypes::No` in coherence. I did not look into this as part of this PR as it is purely changing the structure of the code without changing behavior in any way. r? ```@oli-obk```
This PR removes the
InferCtxt::defining_use_anchor
field and instead bubbles it through the appropriate types and functions that already need to know about their body owner (e.g. hir typeck or mir borrowck/typeck).follow-up to #108311
r? @lcnr