As part of this, we have to change the type export rules to
prevent `@convention(c)` function types from being used in
exported interfaces if they aren't serializable. This is a
more conservative version of the original rule I had, which
was to import such function-pointer types as opaque pointers.
That rule would've completely prevented importing function-pointer
types defined in bridging headers and so simply doesn't work,
so we're left trying to catch the unsupportable cases
retroactively. This has the unfortunate consequence that we
can't necessarily serialize the internal state of the compiler,
but that was already true due to normal type uses of aggregate
types from bridging headers; if we can teach the compiler to
reliably serialize such types, we should be able to use the
same mechanisms for function types.
This PR doesn't flip the switch to use Clang function types
by default, so many of the clang-function-type-serialization
FIXMEs are still in place.
This reverts commit e805fe486e, which reverted
the change earlier. The problem was caused due to a simultaneous change to some
code by the PR with parsing and printing for Clang function types (#28737)
and the PR which introduced Located<T> (#28643).
This commit also includes a small change to make sure the intersecting region
is fixed: the change is limited to using the fields of Located<T> in the
`tryParseClangType` lambda.
Note: The change in ASTBuilder::createFunctionType is functionally minor,
but we need the FunctionType::Params computed _before_ the ExtInfo, so we
need to shuffle a bunch of code around.
For reproducers in LLDB, we need to collect module dependency
information coming from the clang importer. However, we cannot override
the dependency collector, like we do in LLDB, because its interface is
completely hidden in the clang importer. The solution is to pass the
FileCollector through the DependencyTracker.
(cherry picked from commit c624a87bd5)
The only place this was used in Decl.h was the failability kind of a
constructor.
I decided to replace this with a boolean isFailable() bit. Now that
we have isImplicitlyUnwrappedOptional(), it seems to make more sense
to not have ConstructorDecl represent redundant information which
might not be internally consistent.
Most callers of getFailability() actually only care if the result is
failable or not; the few callers that care about it being IUO can
check isImplicitlyUnwrappedOptional() as well.
This refactors DWARFImporter to become a part of ClangImporter, since
it needs access to many of its implementation details anyway. The
DWARFImporterDelegate is just another mechanism for deserializing
Clang ASTs and once we have a Clang AST, the processing is effectively
the same.
Traditionally a serialized binary Swift module (as used in debug info)
can only be imported if all of its Clang dependencies can be imported
*from source*.
- Swift's ClangImporter imports Clang modules by converting Clang AST
types into Swift AST types.
- LLDB knows how to find Clang types in DWARF or other debug info and
can synthesize a Clang AST from that information.
This patch introduces a DWARFImporter delegate that is implemented by
LLDB to connect these two components. With this, a Clang type can be
found (by name) in the debug info and handed over to ClangImporter to
create a Swift type from it. This path has lower fidelity than
importing the Clang modules from source, since it is missing out on
Swiftication annotations and other metadata that is not serialized in
DWARF, but it's invaluable as a fallback mechanism for the debugger
when source code for the Clang modules isn't available or the modules
are otherwise not buildable.
rdar://problem/49233932
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
https://github.com/apple/swift/pull/16951 introduced a layering violation between the
AST and ClangImporter libraries; break the layering violation by moving the function
isInOverlayModuleForImportedModule() to ClangModuleLoader.
(and 'La'...'Lj')
Use this for the synthesized structs for error enums, as described in
the previous commit, instead of reusing the "private discriminator"
feature. I left some space in the APIs for "related entity kinds" that
are longer than a single character, but I don't actually expect to use
it any time soon. It's mostly just easier to deal with StringRef than
with a bare char.
Note that this doesn't perfectly round-trip to the old mangling; I had
it treat these nodes as private discriminators with a prefixed "$"
instead. We don't depend on that for anything, though.
When importing a C enum with the ns_error_domain attribute, we
synthesize a struct containing an NSError object to represent errors
in that domain. That synthesized struct should have a mangled name
that ties it to the original C enum, if we want it to be stable, and
now it does.
Before: $SSC7MyErrorV (a normal struct, which is a lie)
After: $SSC11MyErrorCode13ns_error_enumLLV
kind=Global
kind=Structure
kind=Module, text="__C_Synthesized"
kind=PrivateDeclName
kind=Identifier, text="ns_error_enum"
kind=Identifier, text="MyErrorCode"
Using the "private discriminator" feature allows us to pack in extra
information about the declaration without changing the mangling
grammar, and without stepping on anything the importer is using.
More rdar://problem/24688918
This lets clients look up types by their /Clang/ names. This is going
to be useful for subsequent commits, but can also have independent use
when going from a class name / selector pair.
For the multiple-files mode -emit-pch is still invoked in separate frontend invocation but with using a persistent PCH.
Subsequent frontend invocations use the persistent PCH but they don't need to validate it.
For all-files mode (e.g. WMO) the frontend invocation uses a persistent PCH that it also validates.
- 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
