Most clients were only using it to populate the
main module with files, which is now done by
`getMainModule`. Instead, they can now just rely
on parsing happening lazily.
Lift the `DisablePoundIfEvaluation` parsing option
into `LangOptions` to subsume the need for the
`EvaluateConditionals` parameter, and sink the
computation of `CanDelayBodies` down into
`createSourceFileForMainModule`.
Rather than replacing the code completion file
on the `CompilerInstance` whenever we do a cached
top-level completion, let's set a new main module
instead.
This allows us to properly update the
`LoadedModules` map, and allows the retrieval of
the code completion file to be turned into a
request.
Out handling of clang submodules was handled differently between DocInfo and
InterfaceGen. For InterfaceGen submodules were mapped back to their top-level
clang modules (or their Swift overlay if it had one) before being passed
into printSubmoduleInterface, along with the dot separated name of the submodule.
For DocInfo, they were not, and only the rightmost component of their name was
passed. The call to retrieve the decls from a ModuleDecl doesn't work if the
ModuleDecl wraps a clang submodule, so we were missing these decls.
InterfaceGen for submodules also shouldn't have been mapping the module back to
the overlay of top-level clang module, as that meant we ended up printing
import decls from the Swift overlay in the submodule's interface.
Resolves rdar://problem/57338105
* Don't import C++ class members that are protected or private.
We omit protected members in addition to private members because Swift
structs can't inherit from C++ classes, so there's effectively no way to
access them.
* Check access specifiers centrally in importDeclImpl().
* Fix macOS build by using <stddef.h> instead of <cstddef>.
Apparently, the macOS toolchain doesn't provide <cstddef>.
<stddef.h> is used in test/Inputs/clang-importer-sdk/usr/include/macros.h,
so I'm assuming it will be OK. (I don't unfortunately have a macOS
machine to test on.)
* Add comment explaining why we skip private and protected C++ class
members.
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
Remove the `EvaluateConditionals` flags from the
parser, and instead query the source file.
This commit also changes ParserUnit such that it
doesn't evaluate #if conditions by default, as
none of its clients appear to require it. The
only client that wasn't explicitly disabling #if
evaluation and is processing the resulting AST is
swift-indent, so this commit also adds a test to
ensure it continues to work correctly with #if
decls.
Move the global PersistentParserState from
the CompilerInstance to the source file that code
completion is operating on, only hooking up the
state when it's needed. This will help make it
easier to requestify source file parsing.
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.
in all SourceKit requests.
This validation may call many stat(2). Since we don't expect system files
are edited. Disable it for SourceKit requests. Even if they are edited,
manual builds can validates and updates them.
rdar://problem/58550697
This change ensures using .swiftmodule built from source has the same behavior as
using .swiftmodule built from .swiftinterface.
A swift-ide-test utility is added to print linked libraries from a Swift module for
testing purposes.
rdar://58057556
SourceKit doesn't set up a compiler instance, just a parser, for its syntactic
requests (document structure and syntax coloring). This updates swift-ide-test
to minic this setup to ensure the StructureAnnotator/PrintSyntaxColorWalker and
underlying SyntaxModelWalker handle this setup (which has no type-checker
installed) for all our swift-ide-test based tests.
Resolves rdar://problem/57202584
To controls the lifetime of CompilerInstance within CompletionIntance.
- Prevent from using the same CompilerInstance from multiple completion
requests
- Separate the stacktrace between "fast" and "normal" completions
- Further code consolidation between various completion-like requests
- Introduce ide::CompletionInstance to manage CompilerInstance
- `CompletionInstance` vends the cached CompilerInstance when:
-- The compiler arguments (i.e. CompilerInvocation) has has not changed
-- The primary file is the same
-- The completion happens inside function bodies in both previous and
current completion
-- The interface hash of the primary file has not changed
- Otherwise, it vends a fresh CompilerInstance and cache it for the next
completion
rdar://problem/20787086
SwiftSourceInfo files provide source location information for decls coming from
loaded modules. For most IDE use cases it either has an undesirable impact on
performance with no benefit (code completion), results in stale locations being
used instead of more up-to-date indexer locations (cursor info), or has no
observable effect (live diagnostics, which are filtered to just those with a
location in the primary file).
For non-IDE clients of SourceKit though, cursor info providing declaration
locations for symbols from other modules is useful, so add a global
configuration option (and a new request to set it) to control whether
.swiftsourceinfo files are loaded or not based on use case (they are loaded by
default).
- Stop using skipBracedBlock() in parseDeclPrecedenceGroup(),
skipUntilDeclRBrace() is better at this context.
- Disable 'SyntaxParsingContext' inside skipBracedBlock()
- Removed unsound recovery logic in consumeAbstractFunctionBody(). This
doesn't match with the parser bahavior in the delayed parsing.
- Expose 'skipBracedBlock()' as a Parser instance method so it's usable
from other files.
