Split off the notion of "recording" dependencies from the notion of
"collecting" dependencies. This corrects an oversight in the previous
design where dependency replay and recording were actually not "free" in
WMO where we actually never track dependencies. This architecture also
lays the groundwork for the removal of the referenced name trackers.
The algorithm builds upon the infrastructure for dependency sources and
sinks laid down during the cut over to request-based dependency tracking
in #30723.
The idea of the naive algorithm is this:
For a chain of requests A -> B* -> C -> D* -> ... -> L where L is a lookup
request and all starred requests are cached, once L writes into the
dependency collector, the active stack is walked and at each cache-point
the results of dependency collection are associated with the request
itself (in this example, B* and D* have all the names L found associated
with them). Subsequent evaluations of these cached requests (B* and D*
et al) will then *replay* the previous lookup results from L into the
active referenced name tracker. One complication is, suppose the
evaluation of a cached request involves multiple downstream name
lookups. More concretely, suppose we have the following request trace:
A* -> B -> L
|
-> C -> L
|
-> D -> L
|
-> ...
Then A* must see the union of the results of each L. If this reminds
anyone of a union-find, that is no accident! A persistent union-find
a la Conchon and Filliatre is probably in order to help bring down peak
heap usage...
Define a new type DependencyCollector that abstracts over the
incremental dependency gathering logic. This will insulate the
request-based name tracking code from future work on private,
intransitive dependencies.
* Document a number of legacy conditions and edge cases
* Add lexicon definitions for "dependency source", "dependency sink",
"cascading dependency" and "private dependency"
Convert most of the name lookup requests and a few other ancillary typechecking requests into dependency sinks.
Some requests are also combined sinks and sources in order to emulate the current scheme, which performs scope changes based on lookup flags. This is generally undesirable, since it means those requests cannot immediately be generalized to a purely context-based scheme because they depend on some client-provided entropy source. In particular, the few callers that are providing the "known private" name lookup flag need to be converted to perform lookups in the appropriate private context.
Clients that are passing "no known dependency" are currently considered universally incorrect and are outside the scope of the compatibility guarantees. This means that request-based dependency tracking registers strictly more edges than manual dependency tracking. It also means that once we fixup the clients that are passing "known private", we can completely remove these name lookup flags.
Finally, some tests had to change to accomodate the new scheme. Currently, we go out of our way to register a dependency edge for extensions that declare protocol conformances. However, we were also asserting in at least one test that extensions without protocol conformances weren't registering dependency edges. This is blatantly incorrect and has been undone now that the request-based scheme is automatically registering this edge.
Formalize DependencyScope, DependencySource, and the incremental dependency stack.
Also specialize SimpleRequest to formalize dependency sources and dependency sinks. This allows the evaluator's internal entrypoints to specalize away the incremental dependency tracking infrastructure if a request is not actually dependency-relevant.
A request is intended to be a pure function of its inputs. That function could, in theory, fail. In practice, there were basically no requests taking advantage of this ability - the few that were using it to explicitly detect cycles can just return reasonable defaults instead of forwarding the error on up the stack.
This is because cycles are checked by *the Evaluator*, and are unwound by the Evaluator.
Therefore, restore the idea that the evaluate functions are themselves pure, but keep the idea that *evaluation* of those requests may fail. This model enables the best of both worlds: we not only keep the evaluator flexible enough to handle future use cases like cancellation and diagnostic invalidation, but also request-based dependencies using the values computed at the evaluation points. These aforementioned use cases would use the llvm::Expected interface and the regular evaluation-point interface respectively.
Introduce a request to form an abstract generic signature given a
base signature, additional generic parameters, and additional
requirements. It is meant to provide a caching layer in front of the
generic signature builder.
Switch one direct client of the generic signature builder over to this
mechanism, the formation of a generic signature for an existential
type.
This restores the original spelling of the restriction. This is more
legible and may be something which VS2017 will handle properly.
Thanks to @drodriguez for suggesting this!
Unfortunately, VS2017 does not support the SFINAE expression. This
means that it attempts to parse the `Index < sizeof...(Types)` as a
template parameter resulting in a parse failure. This normalises the
constraint to `0 < sizeof...(Types) - Index`
(`sizeof...(Types) - Index > 0`) which is then wrapped into a ternary to
explicitly convert it to a boolean. This repairs the builds on VS2017.
Introduce some template metaprogramming infrastructure to retrieve the
"nearest" source location to the inputs of a request, and use that to
provide default diagnoseCycle and noteCycleStep implementations. This
will help remove a bunch of boilerplate from new requests.
Encode the input and output parameters for a SimpleRequest instance in a
function type and move the CacheKind to the end, making it easier to
sort out inputs from outputs:
```
class DefaultTypeRequest
: public SimpleRequest<DefaultTypeRequest,
Type(KnownProtocolKind, const DeclContext *),
CacheKind::SeparatelyCached>
```
This patch removes the need for Request objects to provide a default
cycle-breaking value, instead opting to return llvm::Expected so clients
must handle a cycle failure explicitly.
Currently, all clients do the 'default' behavior, but this opens the
possibility for future requests to handle failures explicitly.
Introduce three new requests for name lookup operations that avoid performing
type checking/semantic analysis. They work using syntactic information
(e.g., TypeReprs) and AST-level name lookup operations that will (eventually)
avoid and calls back into type checking. The new requests are:
* Retrieve the superclass declaration of a protocol or class declaration. Use
this request for ClassDecl::getSuperclassDecl() and
ProtocolDecl::getSuperclassDecl().
* Retrieve the types “directly referenced” by a particular location in
an inheritance clause. This query is based on looking at the TypeReprs
and performing fairly-minimal lookup, so it does not involve any Type
computations.
* Retrieve the types “directly referenced” by the underlying type of
a typealias. This query allows us to desugar a typealias without forming
a type.
Along with these is a core operation to transform a set of TypeDecl*s
into a set of NominalTypeDecl*s, looking through typealiases, and
without involving Type at all. The superclass-decl request does this
to find a ClassDecl; other requests will eventually do this to (e.g.)
find all of the protocols mentioned in an inheritance clause.
The bundling of the form of a request (e.g., the storage that makes up a request)
with the function that evaluates the request value requires us to perform
ad hoc indirection to address the AST —> Sema layering violation. For
example, ClassDecl::getSuperclass() calls through the LazyResolver (when
available) to form the appropriate request. This means that we cannot
use the the request-evaluator’s cache when LazyResolver is null, forcing
all cached state into the AST.
Provide the evaluator with a zone-based registration system, where each
request “zone” (e.g., the type checker’s requests) registers
callbacks to evaluate each kind of request within that zone. The
evaluator indirects through this table of function pointers, allowing
the request classes themselves to be available at a lower level (AST)
than the functions that perform the computation when the value isn’t
in the cache (e.g., Sema).
We are not taking advantage of the indirection yet; that’ll come in a
follow-up commit.
Simplify the definition of new request kinds by pulling the parameterization
of caching logic into SimpleRequest itself, so that the caching-related
parts of the contract cannot easily be forgotten.
