-
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
conditional fallback for the !
type
#79366
conditional fallback for the !
type
#79366
Commits on Nov 19, 2020
-
Configuration menu - View commit details
-
Copy full SHA for 1cbde85 - Browse repository at this point
Copy the full SHA 1cbde85View commit details -
Configuration menu - View commit details
-
Copy full SHA for 0005746 - Browse repository at this point
Copy the full SHA 0005746View commit details
Commits on Nov 20, 2020
-
Configuration menu - View commit details
-
Copy full SHA for d8a881b - Browse repository at this point
Copy the full SHA d8a881bView commit details -
shallow resolve target type in coercion
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.)
Configuration menu - View commit details
-
Copy full SHA for 00786cf - Browse repository at this point
Copy the full SHA 00786cfView commit details
Commits on Nov 21, 2020
-
Configuration menu - View commit details
-
Copy full SHA for b3f8d74 - Browse repository at this point
Copy the full SHA b3f8d74View commit details -
Configuration menu - View commit details
-
Copy full SHA for 448eb37 - Browse repository at this point
Copy the full SHA 448eb37View commit details -
move the
sub-unify
check and extend the documentation a bitI 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.)
Configuration menu - View commit details
-
Copy full SHA for b37daab - Browse repository at this point
Copy the full SHA b37daabView commit details
Commits on Nov 23, 2020
-
create
Coercion
obligations given 2 unbound type variablesMotivation: 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.
Configuration menu - View commit details
-
Copy full SHA for a4f357d - Browse repository at this point
Copy the full SHA a4f357dView commit details -
Configuration menu - View commit details
-
Copy full SHA for de3bf35 - Browse repository at this point
Copy the full SHA de3bf35View commit details -
move
fallback_if_possible
and friends to fallback.rsAlong the way, simplify and document the logic more clearly.
Configuration menu - View commit details
-
Copy full SHA for 73b743b - Browse repository at this point
Copy the full SHA 73b743bView commit details -
introduce new fallback algorithm
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 `()`.
Configuration menu - View commit details
-
Copy full SHA for 694d3c8 - Browse repository at this point
Copy the full SHA 694d3c8View commit details -
remove diverging type variables from fn check
The comment seems incorrect. Testing revealed that the examples in question still work (as well as some variants) even without the special casing here.
Configuration menu - View commit details
-
Copy full SHA for 8eda90e - Browse repository at this point
Copy the full SHA 8eda90eView commit details -
remove reliance on "diverging" type variables
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.
Configuration menu - View commit details
-
Copy full SHA for fceb523 - Browse repository at this point
Copy the full SHA fceb523View commit details -
stop categorizing inference variables as diverging when created
Instead, we now rely on the code that looks for a NeverToAny adjustment.
Configuration menu - View commit details
-
Copy full SHA for fc02f0f - Browse repository at this point
Copy the full SHA fc02f0fView commit details -
fix bug in
DepthFirstSearch
where start node was not visitedThis could cause us to visit the start node twice.
Configuration menu - View commit details
-
Copy full SHA for 128de40 - Browse repository at this point
Copy the full SHA 128de40View commit details -
optimization: use a single DepthFirstSearch instead of hashsets
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.
Configuration menu - View commit details
-
Copy full SHA for 4157667 - Browse repository at this point
Copy the full SHA 4157667View commit details