- Add CompilerInvocation::getPCHHash
This will be used when creating a unique filename for a persistent
precompiled bridging header.
- Automatically generate and use a precompiled briding header
When we're given both -import-objc-header and -pch-output-dir
arguments, we will try to:
- Validate what we think the PCH filename should be for the bridging
header, based on the Swift PCH hash and the clang module hash.
- If we're successful, we'll just use it.
- If it's out of date or something else is wrong, we'll try to
emit it.
- This gives us a single filename which we can `stat` to check for the
validity of our code completion cache, which is keyed off of module
name, module filename, and module file age.
- Cache code completion results from imported modules
If we just have a single .PCH file imported, we can use that file as
part of the key used to cache declarations in a module. Because
multiple files can contribute to the __ObjC module, we've always given
it the phony filename "<imports>", which never exists, so `stat`-ing it
always fails and we never cache declarations in it.
This is extremely problematic for projects with huge bridging headers.
In the case where we have a single PCH import, this can bring warm code
completion times down to about 500ms from over 2-3s, so it can provide a
nice performance win for IDEs.
- Add a new test that performs two code-completion requests with a bridging header.
- Add some -pch-output-dir flags to existing SourceKit tests that import a bridging
header.
rdar://problem/31198982
This is purely designed to cheaply compute dependency graphs between
modules, and thus only lists the top-level names (i.e. not submodules)
and doesn't do any form of semantic analysis.
The typedef `swift::Module` was a temporary solution that allowed
`swift::Module` to be renamed to `swift::ModuleDecl` without requiring
every single callsite to be modified.
Modify all the callsites, and get rid of the typedef.
This reverts the contents of #5778 and replaces it with a far simpler
implementation of condition resolution along with canImport. When
combined with the optimizations in #6279 we get the best of both worlds
with a performance win and a simpler implementation.
Based off the PlaygroundTransform, this new ASTWalker leaves calls to __builtin_pc_before and __builtin_pc_after before and after a user would expect a program counter to enter a range of source code.
This is a /slightly/ more user-friendly option than
-debug-time-function-bodies; pass it a limit in milliseconds and
the compiler will warn whenever a function or multi-statement closure
takes longer than that to type-check.
Since it's a frontend option (and thus usually passed with -Xfrontend),
I went with the "joined" syntax as the common case. The usual "separate"
syntax of "-warn-long-function-bodies <N>" is also available.
As a frontend option, this is UNSUPPORTED and may be removed without
notice at any future date.
Additional caveats:
- Other parts of type-checking not measured by this may also be slow.
- May include first-use penalties (i.e. "this is slow because it's
the first function that references an imported type, which causes
many things to be imported")
- Does not report anything whatsoever about other phases of compilation
(SILGen, optimization, IRGen, assembly emission, whatever).
- Does not catch anything accidentally being type-checked multiple times
(a known issue for initial value expressions on properties).
When there is only one source file passed to the frontend, the primary
buffer id can be set to ~0, so this check would fail for some
-parse -verify invocations.
Don't emit warnings if specified at the command line or when working
on a non-primary input file.
https://bugs.swift.org/browse/SR-1012
rdar://problem/25282622
Invoking the following command to `-dump-parse` a file containing SIL
triggers an assertion from within the Swift compiler frontend:
```
swiftc -dump-parse foo.sil
```
The assertion is not coupled with a description of what went wrong.
It turns out the frontend doesn't support `-dump-parse` for SIL files,
although `swiftc -help` wouldn't inform users of that:
```
-dump-parse Parse input file(s) and dump AST(s)
```
As a result, a user may invoke `-dump-parse` on a SIL file and not know
what went wrong. Add an assertion message to inform the user that only
Swift code may be parsed. (`IFK_Swift_Library` here is for the case
where `swiftc -parse-as-library -dump-parse foo.swift` is invoked.)
We want to distinguish the special case of a library built with
-sil-serialize-all, from a SIL function that is [fragile] because
of an explicitly @_transparent or @inline(__always).
For now, NFC.
Now that WitnessChecker is separate from ConformanceChecker, implement
a DefaultWitnessChecker subclass which performs default witness
resolution.
This populates the recently-added ProtocolDecl::DefaultWitnesses map.
Unlike ConformanceChecker, the DefaultWitnessChecker looks up the witness
in any protocol extensions of the protocol, matching the context archetypes
of the requirement against the witness.
For now, we infer default witnesses for all protocols, but don't do
anything with that information. An upcoming SILGen patch will start to
emit thunks and add tests.
Pre-specializations were only used by Onone builds, but were kept inside the standard library dylyb anyways. This commit moves all the pre-specializations into a dedicated Swift module and a dynamic library, which are only used by Onone builds.
This reduces the code size of libswiftCore.dylib by 4%-5%.
Pre-specializations were only used by Onone builds, but were kept inside the standard library dylyb anyways. This commit moves all the pre-specializations into a dedicated Swift module and a dynamic library, which are only used by Onone builds.
This reduces the code size of libswiftCore.dylib by 5%.
Since resilience is a property of the module being compiled,
not decls being accessed, we need to record which types are
resilient as part of the module.
Previously we would only ever look at the @_fixed_layout
attribute on a type. If the flag was not specified, Sema
would slap this attribute on every type that gets validated.
This is wasteful for non-resilient builds, because there
all types get the attribute. It was also apparently wrong,
and I don't fully understand when Sema decides to validate
which decls.
It is much cleaner conceptually to just serialize this flag
with the module, and check for its presence if the
attribute was not found on a type.
Exposes the global warning suppression and treatment as errors
functionality to the Swift driver. Introduces the flags
"-suppress-warnings" and "-warnings-as-errors". Test case include.
Till now, a SIL module would be only verified if an optimization has changed it. But if there were no changes, then no verification would happen and some SIL module format errors would stay unnoticed. This was happening in certain cases when reading a textual SIL module representation, which turned out to be broken, but SIL verifier wouldn't catch it.
Swift SVN r31863
To invoke the front-end on a SIL with whole-module optimizations enabled, execute:
swiftc -frontend myfile.sil
To invoke the front-end on a SIL without whole-module optimizations enabled, add a -primary-file option:
swiftc -frontend -primary-file myfile.sil
To invoke a sil-opt with whole-module optimizations enabled, use the -wmo option:
sil-opt myfile.sil -wmo
This change was need to be able to write SIL unit tests which should be compiled in the WMO mode.
Swift SVN r31862
We normally report a warning when a #available() check will always be true
because of the minimum deployment target. These warnings are potentially
annoying when the developer either cannot change the minimum deployment target
from the default (as in playgrounds) or when doing so is burdensome (as for
interpreted command-line scripts, which would require passing a target triple)
-- so suppress them.
The is a updated version of the reverted r29582, which didn't check for
immediate mode properly.
rdar://problem/21324005
Swift SVN r29646
That's how everything behaved anyway. Might as well make it explicit and
stop special-casing it.
I've left in compatibility for modules built with older compilers so that
people using the OS toolchains aren't immediately unable to debug their apps.
As soon as we change the module format in a more significant way, I can take
this out.
Groundwork for rdar://problem/21254367; see next commit.
Swift SVN r29437
Modules occupy a weird space in the AST now: they can be treated like
types (Swift.Int), which is captured by ModuleType. They can be
treated like values for disambiguation (Swift.print), which is
captured by ModuleExpr. And we jump through hoops in various places to
store "either a module or a decl".
Start cleaning this up by transforming Module into ModuleDecl, a
TypeDecl that's implicitly created to describe a module. Subsequent
changes will start folding away the special cases (ModuleExpr ->
DeclRefExpr, name lookup results stop having a separate Module case,
etc.).
Note that the Module -> ModuleDecl typedef is there to limit the
changes needed. Much of this patch is actually dealing with the fact
that Module used to have Ctx and Name public members that now need to
be accessed via getASTContext() and getName(), respectively.
Swift SVN r28284
Instead of only honoring the last occurrence of -import-module, the frontend now
honors all occurrences of -import-module, making all of the modules specified on
the command line implicitly visible.
This fixes <rdar://problem/20422696>.
Swift SVN r27299
getImportedModules is the canonical way to get imports, whether private,
public, or both. This is especially true now that we have more flags
for SourceFile imports that really shouldn't be consumed by anyone
outside of SourceFile.
In this same vein, provide addImports instead of setImports, since imports
are always additive.
No visible functionality change.
Swift SVN r26634
This flag indicates that internal APIs within the module should be made
available to client code for testing purposes. Currently does nothing.
Not ready for developer consumption yet, ergo a hidden frontend-only flag.
Part of testability (rdar://problem/17732115)
Swift SVN r26292
Separate InputFileKind from SourceFileKind, FrontendOptions will now use
InputFileKind, while Module will use SourceFileKind.
This is in preparation for adding an input file kind for LLVM IR.
rdar://19048891
Swift SVN r25555
Also into a separate file.
Before (swift/Serialization/SerializedModuleLoader.h):
ModuleStatus
SerializedModuleLoader::ValidationInfo
SerializedModuleLoader::ExtendedValidationInfo
SerializedModuleLoader::isSerializedAST
SerializedModuleLoader::validateSerializedAST
After (swift/Serialization/Validation.h):
serialization::Status
serialization::ValidationInfo
serialization::ExtendedValidationInfo
serialization::isSerializedAST
serialization::validateSerializedAST
No functionality change, just a lot of renaming and a bit of reorganizing.
Swift SVN r25226
Until we get a proper fix for rdar://problem/19720334 to close the .pcm
files immediately after reading them, forcefully close all the .pcm file
descriptors at the end of performSema. This avoids file descriptor
leaks that eventually bring down SourceKit.
rdar://problem/19059478
Swift SVN r25038
This implicitly adds the named module as an import of every source file
in the module being compiled. This is not intended to be used generally,
but will be useful for playgrounds.
rdar://problem/19605934
Swift SVN r24905
Parser may stop at some erroneous constructions like stray #else or #endif, in some cases closing brace ‘}’, etc…
continue parsing until we are done.
Swift SVN r24822
This has been long in coming. We always had it in IRGenOpts (in string form).
We had the version number in LangOpts for availability purposes. We had to
pass IRGenOpts to the ClangImporter to actually create the right target.
Some of our semantic checks tested the current OS by looking at the "os"
target configuration! And we're about to need to serialize the target for
debugging purposes.
Swift SVN r24468
These are the same dependencies collected for .d files, including
headers and imported swiftmodules. These can also cause a file to be out
of date.
Part of rdar://problem/19270920
Swift SVN r24334
This is a hidden frontend-only option intended for debugging purposes,
mainly for identifying where in a file the type checker is spending most
of its time. Use with "sort -g" to get the top problem functions.
Swift SVN r23789
