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.
Switch the direct operator lookup logic over to
querying the SourceLookupCache, then switch the
main operator lookup logic over to calling the
direct lookup logic rather than querying the
operator maps on the SourceFile.
This then allows us to remove the SourceFile
operator maps, in addition to the logic from
NameBinding that populated them. This requires
redeclaration checking to be implemented
separately.
Finally, to compensate for the caching that the old
operator maps were providing for imported results,
turn the operator lookup requests into cached
requests.
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.
Factor out the lookup side of TypeChecker::conformsToProtocol so we have
a dependency registration point available for evaluator-based
dependencies that doesn't have re-entrancy problems.
Introduce DirectOperatorLookupRequest &
DirectPrecedenceGroupLookupRequest that lookup
operator and precedence groups within a given
file or module without looking through imports.
These will eventually be used as the basis for the
new operator lookup implementation, but for now
just use them when querying lookup results from
serialized module files.
Turn macro metaprogramming into template metaprogramming by defining a new kind of request that runs operator lookups.
This is the final piece of the puzzle for requestification of the current referenced name tracker system.
Soft revert a09382c. It should now be safe to add this flag back as an optimization to specifically disable lazy member loading instead of all extension loading.
Push the flag back everywhere it was needed, but also push it into lookup for associated type members which will never appear in extensions.
We’re going to start serializing this for public types that have non-public-or-@usableFromInline initializers, so turn it into a request that we can query and cache it in the existing bit.
This allows us use an OptionSet parameter for
the request (as currently we can't directly use it
as a parameter due to not having an == definition
for it). It also allows us to regain default
arguments for the source loc and flag parameters.
Use the request evaluator to get the easier in-module precedence group cycles. Unfortunately, cross-module precedence group cycles are still a possibility, and do not actually cause cyclic request evaluation, so we cannot completely erase the old diagnostics machinery.
Move the machinery itself into the type checker and shift the request into that zone as well to appease the linker.
Define the LookupPrecedenceGroupRequest and OperatorPrecedenceGroupRequest for looking up an unvalidated precedence group declaration and retrieving then validating the precedence group associated with an operator.
This allows us to drop both validateDecl overloads for these types out of the TypeChechecker
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>
```
When building with Visual Studio, the following error is identified:
'SimpleRequest': non-class template has already been declared as a class template
note: see declaration of 'SimpleRequest'
Change the friend declarations to friend the type without the `class` specifier.
Our walk over the requirement interface types meant that
computing the access level of an extension member depended
on type resolution and the GSB.
Fix this by adding a new request that simply collects all
TypeDecls referenced from a TypeRepr, and compute the
extension's maximum access level using that.
If we use Structural rather than Interface type resolution when
walking the extension's requirements, we don't have to build its
generic signature first.
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.
Name lookup within a protocol extension also looks into protocols and
superclasses on the right-hand side of Self constraints in the where
clause, e.g., "Self: Foo". Turn that function into a request to avoid
infinite recursion on invalid code.
Introduce a request for ExtensionDecl::getExtendedNominal() that
uses TypeRepr-based resolution to find the extended nominal
type declaration without going through type resolution.
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.
