We need ClangImporterOptions to be persistent for several scenarios: (1)
when creating a sub-ASTContext to build Swift modules from interfaces; and
(2) when creating a new Clang instance to invoke Clang dependencies scanner.
This change is NFC.
Try to impose a simple structure that splits performing actions from the
pre and post-pipeline conditions. Wherever actions would take more than
a simple return, split them into functions. Refine functions that
perform effects to return status codes when they fail. Finally,
delineate functions that need semantic analysis from those that do not.
Overall this should be NFC.
- deduplicate the logic to compute the resource folder
- install headers and module files in shared and static resource folders
- forward -static flag when calling swiftc with -print-target-info
In order to avoid accidentally implicitly loading modules that are expected but were not provided as explicit inputs.
- Use either SerializedModuleLoader or ExplicitSwiftModuleLoader for loading of partial modules, depending on whether we are in Explicit Module Build or Implicit Module Build mode.
Expand the FrontendOptions to allow the enabling
of the dependency tracker for non-system
dependencies, and switch the previous clients of
`createDependencyTracker` over to using this
option. This ensures that the dependency tracker
is now set only during `CompilerInstance::setup`.
Now that it no longer needs to handle the
parse-only case, we can simplify things by having
`performSema` call into
`performParseAndResolveImportsOnly`.
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.
Rather than waiting until one of the performXXX
methods are called, make sure all the main module's
files have been populated up-front by
`getMainModule`.
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.
Remove the `PrimarySourceFiles` vector from the
frontend and replace it with a request on
ModuleDecl that retrieves the primary files for
the main module.
This is in preparation for having
`CompilerInstance::getMainModule` automatically
populate the main module with files when queried.
Rather than trying to continue the compilation
with an empty main module, let's bail out early if
we expect an implicit stdlib import and fail to
load in the stdlib.
Now that we no longer interleave parsing and
type-checking for SIL, the main file doesn't need
to be handled separately. We can now parse it
along with the rest of the input files and
type-check it along with the rest of the primaries.
This commit also updates `performParseOnly` to
match the order in which the files are now parsed.
Add ModuleImplicitImportsRequest, which computes
the modules that should be implicitly imported by
each file of a given module. Use this request in
import resolution to add all the necessary
implicit imports.
The request computes the implicit imports by
consulting the ImplicitImportInfo, which ModuleDecl
can now be created with. This allows us to remove
uses of `SourceFile::addImports` in favor of
adding modules needed to be implicitly imported to
the ImplicitImportInfo.
- Add `setDefaultPrebuiltCacheIfNecessary` a `CompilerInvocation` method
- Call that while setting up the invocation in `swift-symbolgraph-extract`
- Add `Fsystem` argument to add iOSSupport directory to the search paths
- Add `resource-dir` argument for local builds
rdar://59262057
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.
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.
Centralize part of the routine that selects which resources to free. Then, add an additional condition for -dump-api-path.
Before, if this option were specified along with -emit-llvm or -c, the compiler would try to rebuild the torn-down ModuleDecl and crash trying to access the torn-down ASTContext.
The lifetime of the UnifiedStatsReporter was not entirely clear from context. Stick it in the CompilerInstance instead so it can live as long as the compile job.
It is critical that its lifetime be extended beyond that of the ASTContext, as the context may be torn down by the time code generation happens, but additional statistics are recorded during LLVM codegen.
e.g. Playground.
A single file script is like a single function body; the interface of
the file does not affect any other files.
So when a completion happens in a single file script, re-parse the whole
file. But we are still be able to reuse imported modules.
rdar://problem/58378157
We were previously doing this for the REPL, but
not for swift-ide-test. Move the assignment into
the frontend to make sure its always applied, and
inline `createREPLFile` while we're here.
The REPL was using the CompilerInstance to stash this parameter, then it would immediately move it into IRGen. Drop the setter and pass this data directly.
Rather than parsing all delayed bodies for
`-dump-parse` once we finish parsing, tell the
parser not to delay any bodies. This then allows
us to remove `DelayedDeclLists` from
PersistentParserState.
- 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
