When loading the named members for a given name, we want to load all
of the members with that base name... not only the ones that match the
full name, because the lookup table is indexed by base name and
filtering too early drops candidates.
Fixes rdar://problem/36085994.
Some functions and types are hidden behind feature flags.
_GNU_SOURCE exposes the most symbols and methods in glibc
and musl. Currently only turning it on for the Fuchsia triple.
This works a around search path problems caused by a module existing
in both the build/install directory and the source directory.
<rdar://problem/35714074>
This allows objc interop to be tested on non-darwin platforms. The iOS
runtime is used because the abi is the same as the macOS abi, but without
fragility concerns.
Select the language for the clang importer based on the
`-enable-objc-interop` flag rather than target. This paves the road to
enabling ObjC tests on non-Darwin targets as well as building on Darwin
without ObjC interop.
This includes 'LONG_MAX' in the Darwin module, which is defined by the
system and then immediately redefined by Clang's copy of limits.h.
The general strategy here is that if two definitions of a macro in the
same module are in separate explicit submodules, we need to keep track
of both of them, but if they're in the same explicit submodule then
one is probably deliberately redefining the other. This isn't fully
correct because one explicit submodule could include another explicit
submodule, but it's a good first approximation, which we can refine if
we come across problem cases in practice.
Swift /also/ has the ability to distinguish between ModuleA.MACRO and
ModuleB.MACRO if you've imported both modules, although there's an
issue that the two of them end up getting the same mangled name if you
try to use both in the same compilation unit. (Filed
rdar://problem/34968281.) That ability is preserved with this change.
All of this will likely change if/when we switch to Clang's "local
submodule visibility" mode, which is needed for the C++ Modules TS but
is also incompatible with Apple's SDKs at the moment. In that case,
macros in two separate explicit submodules will no longer have an
'override' relationship just because they're mentioned sequentially in
the module map.
rdar://problem/34413934
Besides saving some calls to stat(), this also causes problems when
the user specifies a search path that Clang already adds by default,
like $SDKROOT/Library/Frameworks/. Why? Because Swift adds its search
paths after Clang has already configured its defaults, but Clang
reconfigures its search paths from scratch when compiling a module to
a PCM file to cache. This led to system search paths being found
sooner in the primary Clang instance than in the PCM files, which in
turn resulted in the PCM files being considered out of date.
This isn't likely to affect people much in practice, but it's better
to get right. (We ran into this during Doug's experiments in making
/System/Library/PrivateFrameworks a default search path in Clang
r313317; turns out that's problematic for other reasons as well.)
rdar://problem/34664596
...so that we don't have to keep coming back to update it every major
release. And also so we can actually put methods on it instead of
using free functions.
No intended behavior change (yet).
forEachDistinctName might produce the same name for Swift 4 and Swift
5, but it's possible that for some reason the name will only work in
one mode or the other. In that case, even though we're trying the
"same" name again, we still want to invoke the callback once more.
Add a boolean return to the callback to support this.
Tests to come at the end of this patch series -- this shows up when in
Swift 3 mode and the canonical version for types is set to Swift 5.
A public C module can be expressed as the combination of several
private modules at build time, where that structure is "collapsed"
into a single public module for client use. In such cases, the symbols
associated with the public module can actually be seen as coming from
the private module (e.g. at the time the Swift overlay is built),
which fools our overlay-specific hacks. When a module states that it
is re-exported via another, public module, teach semantic analysis to
treat the entity "as if" it came from the re-exporting public module.
Part of rdar://problem/34438586.
The etymology of these terms isn't about race, but "black" = "blocked"
and "white" = "allowed" isn't really a good look these days. In most
cases we weren't using these terms particularly precisely anyway, so
the rephrasing is actually an improvement.
In order to allow LLDB to debug an app as it was written (in theory),
we stuff a semi-preprocessed version of the bridging header into the
generated swiftmodule file, so that we can fall back on it if the
original bridging header is deleted. The specific functionality we
want is in Clang's -rewrite-includes option, but we need to write to
an in-memory buffer instead of a file.
The existing code took the meat of clang::RewriteIncludesAction and
recreated it manually. We got away with this in the past, but upstream
Clang has changed how clang::RewriteIncludesAction works, and now what
we were doing before results in the (unused) file output stream being
deallocated before the (also unused) buffering stream wrapped around
it. Rather than continue trying to half-use an existing Clang
FrontendAction, just make a new one that does the thing we want and
nothing else.
I'd like to revisit this whole idea in the future -- it doesn't
actually preserve debuggability in the case where the bridging header
may have changed, because we don't check for modifications in all the
things it includes. But for now this should preserve the existing
functionality.
rdar://problem/33693128
This avoids having to bring in all members (and extensions!) for an
outer type just to look up a nested type. In the test case attached
(reduced from the project in SR-5284), this actually led to a circular
dependency between deserialization and the importer, which resulted in
a compiler crash.
This is not a new problem, but it's more important with the release of
Swift 4, where a number of Apple SDK types are now newly imported as
member types. (The one in the original bug was
NSView.AutoresizingMask, formerly NSAutoresizingMaskOptions.) Since we
always use the Swift 4 name for cross-references, this affected
everyone, even those still compiling in Swift 3 mode.
https://bugs.swift.org/browse/SR-5284
Special DeclNames represent names that do not have an identifier in the
surface language. This implies serializing the information about whether
a name is special together with its identifier (if it is not special)
in both the module file and the swift lookup table.
Clang's equivalent of this is mapping fatal errors to non-fatal errors.
This isn't something we really care about for users since it's so rare,
but we do use it in our tests, like this one that's been disabled for
a long time.
rdar://problem/30287833
