Requestify Witness Resolution #28009
Conversation
|
@swift-ci please test |
|
@swift-ci please test source compatibility |
|
@DougGregor I think the right way to do this is to make a checker that acts like a pure function from a top-level target requirement and a (partial) |
|
Build failed |
|
Build failed |
CodaFi
force-pushed
the
witness-requests
branch
from
db6b24c to
b68e2b8
Compare
lib/AST/ProtocolConformance.cpp
Outdated
|
|
||
| void swift::simple_display(llvm::raw_ostream &out, | ||
| const ProtocolConformance *conf) { | ||
| conf->dump(out); |
There was a problem hiding this comment.
Should I worry about this causing other requests to fire?
There was a problem hiding this comment.
This is a placeholder... I'll fix it up.
There was a problem hiding this comment.
Oh wow, the printer can kick off interface type requests for var decls which can perform arbitrarily large amounts of type checking. Lovely.
| } | ||
|
|
||
| void TypeWitnessRequest::cacheResult(TypeWitnessAndDecl typeWitAndDecl) const { | ||
| // FIXME: Refactor this to be the thing that warms the cache. |
There was a problem hiding this comment.
Yikes, but okay; I see your goal here.
Witness matching is a source of a lot of ad-hoc cycles, and mixes the logic that performs resolution, caching, validation, and cycle detection into one place. To make matters worse, some checkers kick off other checks in order to cache work for further declarations, and access an internal cache on their subject conformance for many requirements at once, or sometimes just one requirement. None of this fits into the request evaluator's central view of the caching. This is further evidenced by the fact that if you attempt to move the caching step into the evaluator, it overcaches the same witness and trips asserts. As a start, define requests for the resolution steps, and flush some hacks around forcing witness resolution. The caching logic is mostly untouched (the requests don't actually cache anything), but some cycle breaking is now handled in the evaluator itself. Once witness matching has been refactored to cache with the evaluator, all of these hacks can go away. My urge to destroy the LazyResolver outweighs the compromises here.
CodaFi
force-pushed
the
witness-requests
branch
from
b68e2b8 to
bf6d8e0
Compare
|
@swift-ci please smoke test |
Witness matching is a source of a lot of ad-hoc cycles, and mixes the
logic that performs resolution, caching, validation, and cycle breaking into one
place. To make matters worse, some checkers kick off other checks in
order to cache work for further declarations, and access an internal
cache on their subject conformance for many requirements at once, or
sometimes just one requirement.
None of this fits into the request evaluator's central view of
caching. This is further evidenced by the fact that if you attempt to
move the caching step into the evaluator, it overcaches the same
witness and trips asserts.
As a start, define requests for the resolution steps, and flush some
hacks around forcing witness resolution. The caching logic is mostly
untouched (the requests don't actually cache anything), but some cycle
breaking is now handled in the evaluator itself. Once witness matching
has been refactored to cache with the evaluator, all of these hacks can
go away.
My urge to destroy the LazyResolver outweighs the compromises here.