[Constraint system] Make solver less expression-centric, part N/M #29563
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Make this type suitable for representing the result of solution application, and do so.
Add the final conversion type and the flag indicating whether a given expression is discarded to SolutionApplicationTarget, rather than separating the arguments to the solver implementation.
Now that we have a unified notion of a SolutionApplicationTarget, use it to collapse 3 applySolution-ish functions into one.
Baby steps toward generalizing the expression-centric solver core.
…nFailed() This function isn’t needed, because we can report the failure to the caller directly rather than go through a callback.
Failures will be reported to clients; this callback is unnecessary.
We don’t need this fallback path.
It doesn’t do anything any more, because we’re handling error diagnostics locally without callbacks. Also collapse typeCheckExpressionImpl() into typeCheckExpression().
Only one client was using this, and its logic is trivially inlined into appliedSolution().
Start cleaning up the main “solve” entry point for solving an expression and applying the solution, so it handles arbitrary solution targets. This is another small step that doesn’t do much on its own, but will help with unifying the various places in the code base where we run the solver.
|
@swift-ci please smoke test |
|
@swift-ci please test source compatibility |
|
Also, there's still a bunch of wanton mutation of parameters going on here. It'll get better as more of the larger thrust of the refactoring (to eliminate |
xedin
approved these changes
Jan 31, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Further generalize the constraint solver's entry points to make it less tied to a single expression, which involves a number of steps:
SolutionApplicationTargetso it can hold contextual type information, transformed function bodies, etc. This will capture all of the "top-level" things that we can solve in one shotsolveto work with aSolutionApplicationTargetand make the interface less stateful. We're not yet at the point where we can switch other clients over, but it's closerExprTypeCheckListener, which is tied to the notion of a top-level expression. Focus on the easy parts of it to remove.