This option stopped working when clang changed its default behaviour to
-fmodules-validate-system-headers; we now need to explicitly disable it
to preserve the behaviour of our flag.
rdar://problem/50908762
Previously 'isSystemModule()' returns true only if the module is:
- Standard library
- Clang module and that is `IsSystem`
- Swift overlay for clang `IsSystem` module
Now:
- Clang module and that is `IsSystem`; or
- Swift overlay for clang `IsSystem` module
- Swift module found in either of these directories:
- Runtime library directoris (including stdlib)
- Frameworks in `-Fsystem` directories
- Frameworks in `$SDKROOT/System/Library/Frameworks/` (Darwin)
- Frameworks in `$SDKROOT/Library/Frameworks/` (Darwin)
rdar://problem/50516314
This commit adds a new type DynamicLookupInfo that provides information
about how a dynamic member lookup found a particular Decl. This is
needed to correctly handle KeyPath dynamic member lookups, but for now
just plumb it through everywhere.
Way back in Swift 1 I was trying to draw a distinction between
"overlays", separate libraries that added Swift content to an existing
Objective-C framework, and "the Swift part of a mixed-source
framework", even though they're implemented in almost exactly the same
way. "Adapter module" was the term that covered both of those. In
practice, however, no one knew what "adapter" meant. Bring an end to
this confusion by just using "overlay" within the compiler even for
the mixed-source framework case.
No intended functionality change.
This is an attribute that gets put on an import in library FooKit to
keep it from being a requirement to import FooKit. It's not checked at
all, meaning that in this form it is up to the author of FooKit to
make sure nothing in its API or ABI depends on the implementation-only
dependency. There's also no debugging support here (debugging FooKit
/should/ import the implementation-only dependency if it's present).
The goal is to get to a point where it /can/ be checked, i.e. FooKit
developers are prevented from writing code that would rely on FooKit's
implementation-only dependency being present when compiling clients of
FooKit. But right now it's not.
rdar://problem/48985979
...in preparation for me adding a third kind of import, making the
existing "All" kind a problem. NFC, except that I did rewrite the
ClangModuleUnit implementation of getImportedModules to be simpler!
Previously, we would assert that there's a runtime resource dir
available, but then accept the possibility of no glibc.modulemap. We
should just do the same thing for 'no resource dir' as 'no module map'.
This reapplies four commits for the ClangImporter. They broke the build
on master because the associated commits on swift-clang's
swift-5.1-branch never made it to stable due to automerger woes. This
time I'll push everything through manually.
These are the commits being reapplied:
- a42bc62397 "ClangImporter: Share a module cache between CompilerInstances"
- 9eed34235b "ClangImporter: Adjust to r355777, PCMCache => ModuleCache"
- da8a1c57e8 "ClangImporter: Use the new CacheGeneratedPCH in Clang"
- 2134b17a20 "ClangImporter: Test that PCHs are actually cached in memory"
rdar://problem/48545366
This flag causes the generated PCH to be written into the in-memory
module cache. Every CompilerInstance that tries to read the PCH will
use it rather than reading a potentially-since-overwritten version from
the filesystem.
rdar://problem/48740787
(cherry picked from commit 236fc19121)
Share an in-memory module cache between Clang compiler instances to
maintain a consistent view of the implicitly-generated PCMs, protecting
against filesystem races. This cache is more robust after r355778.
Note that there are still potential races for PCHs; I'll fix that in a
follow-up.
rdar://problem/48545366
(cherry picked from commit bf0e9a70c6)
Upstream Clang renamed getPCMCache() to getModuleCache() in r355777,
stopped passing it the Preprocessor passing it directly to ASTReader
instead. Adapt to those API changes.
rdar://problem/48545366
(cherry picked from commit 131cff72b2)
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.
