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
When we remove Sema's UsedConformances list, conformances to _BridgedStoredNSError
are checked from SILGen, where its too late to check function bodies of synthesized
functions.
We could solve this by adding a callback to type check a synthesized function's
body, but in fact all synthesized functions are rather trivial so it's better to
build their bodies fully type checked.
Start by building fully checked expressions for various accessors in ClangImporter.
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.
The special rule for NSUInteger in system headers was colliding with
the behavior of NS_TYPED_ENUM (swift_newtype/swift_wrapper). Let
NS_TYPED_ENUM take precedence here.
(I also future-proofed this for BOOL and Boolean, but those don't
NS_TYPED_ENUM correctly right now for another reason: Bool is bridged
to Objective-C via NSNumber, but ObjCBool is not, even though it could
be.)
rdar://problem/50076612
This allows the conversion of the Windows `BOOL` type to be converted to
`Bool` implicitly. The implicit bridging allows for a more ergonomic
use of the native Windows APIs in Swift.
Due to the ambiguity between the Objective C `BOOL` and the Windows
`BOOL`, we must manually map the `BOOL` type to the appropriate type.
This required lifting the mapping entry for `ObjCBool` from the mapped
types XMACRO definition into the inline definition in the importer.
Take the opportunity to simplify the mapping code.
Adjust the standard library usage of the `BOOL` type which is now
eclipsed by the new `WindowsBool` type, preferring to use `Bool`
whenever possible.
Thanks to Jordan Rose for the suggestion to do this and a couple of
hints along the way.
* Moves the IsStatic flag from VarDecl to AbstractStorageDecl.
* Adds a StaticSubscriptKind to SubscriptDecl.
* Updates serialization for these changes.
* Updates SubscriptDecl constructor call sites for these changes.
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!
* Teach the importer to import any vector type as SIMDN<Scalar>.
Instead of having a known set of vector types, check to see if the
element type conforms to SIMDScalar; if it does, see if we have a
SIMDN defined with the right number of elements. If both are satisfied,
import the vector type as that Swift type.
By making this change, we gain the ability to import vector types
that aren't defined in terms of the Darwin simd module, which lets
us use C API with vector types on other platforms. It also lets us
import *every* vector type that Swift can represent, rather than the
small subset that are currently hardcoded.
* Increased test coverage for increased SIMD types that we can import.
Includes some minor cleanup from review. Also eliminates the old
simd_sans_simd test, since we can now import all of these types even when the simd module isn't imported.
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
This is a follow up to the discussion on #22740 to switch the host
libraries to use the `target_link_libraries` rather than the
`LINK_LIBRARIES` special handling. This allows the dependency to be
properly tracked by CMake and allows us to use the more modern syntax.
The getLocStart API is deprecated and slated for removal from LLVM
very soon. Switch to use getBeginLoc instead. I did not see any uses
of the corresponding getLocEnd API.
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
As a follow-on to the fix for rdar://problem/47564982, a type
parameter in a generic Objective-C class whose type bounds include
both a NSObject-derived superclass and a protocol would have been
classified has being Hashable, when in fact the corresponding
existential type will not conform to Hashable. Only allow hashability
when there are no protocol requirements.
`#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.
