This reverts commit fa2a5779b1.
The Clang change associated with this is only on swift-5.0-branch as a
temporary solution. Bruno is working on a better fix for trunk, so the
Swift master-next branch should not include this.
rdar://problem/37828424
This sets the NeededByPCHOrCompilationUsesPCH language option when
emitting a brigding PCH.
rdar://problem/35056912
rdar://problem/30384801
Initial patch by Adrian Prantl
(cherry picked from commit 5d5f542fe4)
This sets the NeededByPCHOrCompilationUsesPCH language option when
emitting a brigding PCH.
rdar://problem/35056912
rdar://problem/30384801
Initial patch by Adrian Prantl
(cherry picked from commit 5d5f542fe4)
Previously the recommended pattern for having a "private" interface
for a public framework that was easy to strip out was to define an
explicit submodule named 'Private'. However, that makes it all too
easy to have dependencies from the public parts of the module on the
private parts, and other such problems. We're now recommending that
the private module map instead define a parallel module named with
"_Private" as a suffix. Clang already implemented this, but Swift
didn't get the same treatment.
This fix tries to avoid hardcoding too much; it notes that this kind
of remapping is limited to the name 'Private' as the second component
of a module hierarchy, but doesn't actually encode the mapping with the
"_Private" suffix.
rdar://problem/37553763
Like 0d347ac1, but for bridging headers. We can have multiple bridging
headers if someone is sneaking them into a library target, even though
we've tried to lock down on that. Up until now we've been pretending
they're all included at offset 0 in the dummy main source file, but
that causes problems in rare occasions involving precompiled headers.
(I'm being vague about what those circumstances are because I haven't
actually nailed them down yet, nor have I reduced the reproducing
project to something that can be checked in as a regression test. But
it's something like "we encountered this header through a particular
include path, but we thought that include path led to a different
header".)
Instead, reuse the fix we had for module imports: a monotonically
increasing include location in a fake (but allocated) buffer. This
will still put the bridging header first under normal circumstances,
but will also handle a mix of module imports and extra bridging
headers being loaded.
rdar://problem/34349832
If a bridging header imported a submodule but /not/ the top-level
module, the top-level module would never be made visible. This is a
problem since the Clang importer makes all top-level decls available
through their enclosing top-level modules, not the individual
submodules.
To fix this, stop special-casing the way we handle bridging header
imports; we can translate them from Clang Modules to Swift ModuleDecls
the same way we do for regular imports.
rdar://problem/37355259
...rather than the ad hoc CustomTypeNameManglingAttr I was using
before. As John pointed out, the AST should be semantic wherever
possible.
We may someday want to get out of this being an attribute altogether,
or duplicating information that's available in the original Clang
node, by actually storing a reference to that node somewhere. This is
tricky and mixed up with deciding what hasClangNode() or
getClangDecl() would mean, though, so for now the attribute just
carries the information we need.
(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
Previously headers from the bridging header and imported modules had the exact same top location so comparison with them
was not sound. This resulted in missing documentation comments from declarations and possible assertion hits while clang
was trying to determine the comment for a declaration, but I could not create a reduced test case that triggered an assertion hit.
rdar://34925466
ClangImporter::lookupTypeDecl allows a Clang type declaration to be
imported by Clang name instead of by Swift name. Now that we're using
Clang names in mangled names, that's exactly what we need to
reconstruct an AST type from a mangled name.
Also:
- Handle @compatibility_alias in ClangImporter::lookupTypeDecl
- Print errors when type reconstruction fails in swift-ide-test
- Add an extra test for RemoteAST
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.
As of Clang r321099, the OS version specified on the target triple is
sufficient. Note that Arnold independently came up with this same patch
in https://github.com/apple/swift/pull/13556.
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
