Refactor the PlatformAvailability logic for determining
which Clang availability attributes are relevant when importing. The goal
is to separate the logic for attribute relevance for a given platform from
the logic to determine whether a deprecated attribute should be imported as
unavailable in Swift.
This also makes it possible for the "deprecated-as-unavailable" logic to
refer to the underlying Clang declaration, which is functionality that will
be used in a later commit.
This commit has no intended functional change.
Part of rdar://problem/48348822
The loading of additional modules by Sema may trigger an out-of-date
PCM rebuild in the Clang module dependencies of the additional
module. A PCM rebuild causes the ModuleManager to unload previously
loaded ASTFiles. For this reason we must use the cached ASTFile
information here instead of the potentially dangling pointer to the
ASTFile that is stored in the clang::Module object.
This fixes a crash in IRGenDebugInfo when generation DIModule context
chains.
rdar://problem/47600180
`#import` on Windows is problematic at as the default behaviour in C/C++
mode is to be an import of a type library (COM feature). This can be
adjusted by always enabling Objective-C interop on Windows, but the
runtime is not always built with ObjC interop.
Unfortunately, always using `#include` breaks semantics on Apple where
some places rely on the include-once semantics of `#import`.
For now, control the inclusion technique to be based on whether ObjC
interop is enabled or not.
Clang importer was picking the beginning of the main FileID as include location of its modules, which is the same location that the clang PCH mechanism is using as import location.
Make sure to use a different location otherwise we'll have problems with source order comparisons of clang source locations not being deterministic.
rdar://29137319
Windows SDK requires that the platform target is identified.
Unfortunately, `cl` does not specify the value, so we cannot actually
specify the value in the clang frontend. Specify this in the swift
frontend as this obscures the clang invocation.
They're all the same anyway, and no longer even need to be compiled,
just copied in as text.
And drastically simplify how we "generate" them. Instead of attaching
their build jobs to the appropriate overlays, if present, "just" have
one job to copy them all and attach it to the Darwin overlay. That's
what we do for the overlay shim headers, and it's good enough.
(Eventually we want to get out of the business of shipping them
altogether.)
This does have the same flaw as the shim headers: if you /just/ change
API notes, the corresponding overlay does not get rebuilt. You have to
touch that too. But in practice that'll happen most of the time
anyway.
Part of rdar://problem/43545560
It's not something that /ought/ to happen, but when modules aren't
quite set up properly (often by accident, thanks to header maps), we
can get into basically this situation by having the definition end up
in a header that's textually included into two different modules, or
into a module and a bridging header. Handle that the same way we
handle other redeclarations: have it show up in both modules.
rdar://problem/45646620
This sets the NeededByPCHOrCompilationUsesPCH language option when
emitting a brigding PCH.
rdar://problem/35056912
rdar://problem/30384801
rdar://problem/45714111
Initial patch by Adrian Prantl
(cherry picked from commit 5d5f542fe4)
(cherry picked from commit fa2a5779b1)
We treat redeclarable Clang declarations as present in every module
where they're declared, except for struct/enum/union declarations
where we only count full definitions. This logic requires going from
the imported Swift declaration back to the Clang declaration,
something that's not really possible for "synthesized declarations"
today. The only top-level synthesized declarations we have right now
are the structs we make to wrap error code enums.
The 100% correct thing to do would be to account for people defining
error code enums consistently across multiple modules. In practice,
though, error code enums are used with Objective-C (the importer's
treatment of them is tied to NSError), where redefining existing types
is very unusual. Therefore, this fix just ignores redeclarations of
error code enums, whether they're definitions or not.
rdar://problem/45414271
Android Bionic offers lgammaf_r and lgamma_r only if _GNU_SOURCE is
provided. It also offers lgammal_r in API levels 23 and above, but
that one will not be available until 128 bit floats are supported.
The patch modifies the importer to use _GNU_SOURCE while importing
Android headers and slighly modify a check that was avoding the
function from being created for Android.
This fixes the compilation of the tgmath test in Android.
This silences the instances of the warning from Visual Studio about not all
codepaths returning a value. This makes the output more readable and less
likely to lose useful warnings. NFC.
StringMap always copies its strings into its own storage. A DenseMap
of StringRefs has the same caveats as any other use of StringRef, but
in the cases I've changed the string has very clear ownership that
outlives the map.
No functionality change, but should reduce memory usage and malloc
traffic a little.
Any configuration where the stdlib doesn't exist is an atypical one,
but being more permissive here lets us successfully import many kinds
of declarations even without a stdlib. That in turn makes it possible
to write IRGen tests that need foreign types and exercise a specific
target without restricting the test to only run when building that
target.
Package up the logic that generates a full Clang module name, so that
(a) we don't have to deal with clang::Module in quite as many places
in the /Swift/ compiler, and (b) we can avoid the cost of a temporary
string in a few places.
The main places where this is /not/ adopted is where we don't just
want to know the parent module name, but actually the module itself.
This is mostly indexing-related queries, which use the very similar
ModuleEntity class also defined in Module.h. I didn't quite see an
obvious way to unify these, but that might be where we want to go.
No functionality change.
- getAsDeclOrDeclExtensionContext -> getAsDecl
This is basically the same as a dyn_cast, so it should use a 'getAs'
name like TypeBase does.
- getAsNominalTypeOrNominalTypeExtensionContext -> getSelfNominalTypeDecl
- getAsClassOrClassExtensionContext -> getSelfClassDecl
- getAsEnumOrEnumExtensionContext -> getSelfEnumDecl
- getAsStructOrStructExtensionContext -> getSelfStructDecl
- getAsProtocolOrProtocolExtensionContext -> getSelfProtocolDecl
- getAsTypeOrTypeExtensionContext -> getSelfTypeDecl (private)
These do /not/ return some form of 'this'; instead, they get the
extended types when 'this' is an extension. They started off life with
'is' names, which makes sense, but changed to this at some point. The
names I went with match up with getSelfInterfaceType and
getSelfTypeInContext, even though strictly speaking they're closer to
what getDeclaredInterfaceType does. But it didn't seem right to claim
that an extension "declares" the ClassDecl here.
- getAsProtocolExtensionContext -> getExtendedProtocolDecl
Like the above, this didn't return the ExtensionDecl; it returned its
extended type.
This entire commit is a mechanical change: find-and-replace, followed
by manual reformatted but no code changes.
There are three modes of concern here:
1) User provides -vfsoverlay but not -Xcc -ivfsoverlay
Recommended behavior.
2) User provides -Xcc -ivfsoverlay but not -vfsoverlay
Legacy behavior. Clang will handle setup for the VFS.
3) User provides both -vfsoverlay and -Xcc -ivfsoverlay
Unsupported. We will ignore the clang VFS overlays and substitute our
own. We will also pop a warning about this.
Adds the -vfsoverlay frontend option that enables the user to pass
VFS overlay YAML files to Swift. These files define a (potentially
many-layered) virtual mapping on which we predicate a VFS.
Switch all input-based memory buffer reads in the Frontend to the new
FileSystem-based approach.
ClassDecl::getSuperclass() produces a complete interface type describing the
superclass of a class, including any generic arguments (for a generic type).
Most callers only need the referenced ClassDecl, which is (now) cheaper
to compute: switch those callers over to ClassDecl::getSuperclassDecl().
Fixes an existing test for SR-5993.
The documentation for this method states that this can return null if
the module unit represents [the] imported headers.
We have a crash report on dereferencing the result of this function
farther down, and I suspect it's hitting exactly that
case. Unfortunately we only have a back trace and no test case.
Fixes: rdar://problem/41888568
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.
If the Clang declrations are *types*, canonical declaration in Swift is
imported for newest version of Swift. In interface generation, if the
declaration is versioned and it's imported as a member in either or both
version of Swift, we have to take compatibility typealias into account.
* Fixed 'ClangModuleUnit::getTopLevelDecls' to take isCompatibilityAlias() into account
* Fixed bugs in ClangImporter where member-to-member versioned types aren't properly imported.
* Fixed 'SwiftDeclConverter::importFullName' to check equality of getEffectiveContext()
* Fixed 'importer::addEntryToLookupTable' to check equality of getEffectiveContext()
(moved 'ClangImporter::Implementation::forEachDistinctName' to 'NameImporter')
