-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
[WIP] Experiment: stabilize never type #79470
[WIP] Experiment: stabilize never type #79470
Conversation
We used to avoid doing this because we didn't want to make coercion depend on the state of inference. For better or worse, we have moved away from this position over time. Therefore, I am going to go ahead and resolve the `b` target type early on so that it is done uniformly. (The older technique for managing this was always something of a hack regardless; if we really wanted to avoid integrating coercion and inference we needed to be more disciplined about it.)
I didn't like the sub-unify code executing when a predicate was ENQUEUED, that felt fragile. I would have preferred to move the sub-unify code so that it only occurred during generalization, but that impacted diagnostics, so having it also occur when we process subtype predicates felt pretty reasonable. (I guess we only need one or the other, but I kind of prefer both, since the generalizer ultimately feels like the *right* place to guarantee the properties we want.)
Motivation: in upcoming commits, we are going to create a graph of the coercion relationships between variables. We want to distinguish *coercion* specifically from other sorts of subtyping, as it indicates values flowing from one place to another via assignment.
Along the way, simplify and document the logic more clearly.
We now fallback type variables using the following rules: * Construct a coercion graph `A -> B` where `A` and `B` are unresolved type variables or the `!` type. * Let D be those variables that are reachable from `!`. * Let N be those variables that are reachable from a variable not in D. * All variables in (D \ N) fallback to `!`. * All variables in (D & N) fallback to `()`.
The comment seems incorrect. Testing revealed that the examples in question still work (as well as some variants) even without the special casing here.
Instead, we now record those type variables that are the target of a `NeverToAny` adjustment and consider those to be the "diverging" type variables. This allows us to remove the special case logic that creates a type variable for `!` in coercion.
Instead, we now rely on the code that looks for a NeverToAny adjustment.
This could cause us to visit the start node twice.
Extend the `DepthFirstSearch` iterator so that it can be re-used and extended with add'l start nodes. Then replace the FxHashSets of nodes we were using in the fallback analysis with a single iterator. This way we won't re-walk portions of the graph that are reached more than once, and we also do less allocation etc.
r? @oli-obk (rust-highfive has picked a reviewer for you, use r? to override) |
@bors try |
r? @ghost |
⌛ Trying commit 5ef3eb6 with merge 449cf216550e3ee885a40c684da555a6ab31a065... |
☀️ Try build successful - checks-actions |
_FC(X), | ||
_FD(X), | ||
_FE(X), | ||
_FF(X), | ||
|
||
V3, |
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.
Should we be fixing rustfmt here or telling rustfmt to skip this?
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 think you'll want to post any comments on #79366 as this PR is just for the purpose of running crater
I would start crater, but I don't know if just a check suffices or if we also need to run all tests |
@craterbot build-and-test check would probably suffice but it is possible for these changes to change the semantics of running code and so forth. |
🚨 Error: failed to parse the command 🆘 If you have any trouble with Crater please ping |
@bors try |
⌛ Trying commit 3ad1e4d with merge b2f80f6008cdafc35b4472bd46afa16cc6b0cd63... |
☀️ Try build successful - checks-actions |
@craterbot check I'm going to start with a check build and we can consider a run-and-test check later. |
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
Seems like it'll be a while :) |
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🎉 Experiment
|
Relatively few root failures, but definitely some impact. I did a bit of digging but will have to read in more carefully. One sample error (chmlib v1.0.0):
|
AFAIK there are three root failures: "trait is not implemented for
|
Follow-up to #79366 for the purposes of running crater