You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 902ebb2
Browse filesBrowse the repository at this point in the historyBrowse files
Use both sides of type context for generic type inference (part 1) (#22286)
Ref #22063Fixes#4150Fixes#5311Fixes#5874Fixes#5971Fixes#8861Fixes#10105Fixes#12760Fixes#15087Fixes#15462Fixes#15569Fixes#16310Fixes#16376Fixes#16953Fixes#17025Fixes#17694Fixes#18233Fixes#18236Fixes#18267Fixes#18427Fixes#18689Fixes#19259Fixes#19304Fixes#20219Fixes#20648Fixes#21532Fixes#21796Fixes#21809
I think this is the right thing to do, even though this unfortunately
(but unsurprisingly) causes some visible slow-down (because we infer
2-3x more constraints):
```
master 4.013s (0.0%) | stdev 0.011s
new-inference 4.081s (+1.7%) | stdev 0.005s
```
I add couple micro-optimizations in relevant code paths to minimize the
impact.
The implementation is generally straightforward: use both sides buy
default, and only fall back to outer context if there are problems (to
give consistent type errors). My plan is to split the change into few
smaller things:
1. Basic implementation of the idea (this PR).
2. Targeted improvements of meet/join (as needed).
3. Targeted improvements to the solver such us meet sorting and/or
priming.
4. Update the second pass of argument inference in the same manner.
5. Remove (most of) existing special-casing (depends on step 4).
6. Fix false-negative bug due to `Any` leaking from partial context.
This is present on master and quite benign, but may happen more often
with the new logic.
7. Implement some targeted performance optimizations (like removing
`pre_validate_solutions` hack, and making protocol checks faster).
0 commit comments