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.
If a cross-import overlay shadows another module and has a name starting with
'_', don't present that overlay in places where module name completions are
offered and present symbols comining from that module as if they came from
the shadowed module instead.
Resolves rdar://problem/59445688
We previously computed cross-imports by comparing N transitive imports against N transitive imports. This is wasteful, because at least one of the two modules in a pair has to actually declare a cross-import overlay for us to discover one, and the vast majority of modules don’t declare any.
This commit makes us instead compare N transitive imports against M transitive imports which are known to declare at least one cross-import overlay. Since N is potentailly in the thousands while M is perhaps in the double digits, this should be good for a substantial time savings.
However, this optimization has made a test of another cross-import performance optimization fail—not because we have regressed on that, but because it skips work the test case expects us to perform. I have XFAILed that test for now.
Fixes <rdar://problem/59538458>.
Add flags for whether delayed body parsing or #if
condition evaluation is disabled, as well as
whether warnings should be suppressed. Then pass
down these flags from the frontend.
This is in preparation for the requestification of
source file parsing where the SourceFile will need
to be able to parse itself on demand.
When a “separately imported overlay” is added to a SourceFile, two things happen:
1. The direct import of the underlying module is removed from getImports*() by default. It is only visible if the caller passes ImportFilterKind:: ShadowedBySeparateOverlay. This means that non-module-scoped lookups will search _OverlayModule before searching its re-export UnderlyingModule, allowing it to shadow underlying declarations.
2. When you ask for lookupInModule() to look in the underlying module in that source file, it looks in the overlays instead. This means that UnderlyingModule.foo() can find declarations in _OverlayModule.
Tests seem to pass without these.
Two calls still remain, in ModuleDecl::addFiles() and removeFiles().
It will take a bit more refactoring to eliminate those.
- Add DocRangesLayout to the `.swiftsourceinfo`.
This is a blob containing an array of `SingleRawComment`
source locations.
- Add DocLocWriter for serializing `SingleRawComment` locs into the
`DocLocsLayout` buffer.
Serialize start line, start column, and length of `SingleRawComment`
pieces in `.swiftsourceinfo`
- Read doc locs when loading basic declaration locs from a ModuleFile.
- Load `DOC_LOCS` blob into ModuleFile::DocLocsData
- Reconstitute RawComment ranges when available from .swiftsourceinfo
- Allow requesting serialized raw comment if available
rdar://problem/58339492
Add an alternative to getTopLevelDecls and getDeclChecked to limit which
decls are deserialized by first looking at their attributes. If the
attributes are accepted by a function passed as argument the decl is
fully deserialized, otherwise it is ignored.
The filter is included in the signature of existing functions in the
Serilalization services, but I’ve added new methods for it in FileUnit
and its subclasses to leave existing implementations untouched.
