Previously we set up the diagnostic options too early for these flags
to be honored, in order to diagnose problems in parsing the arguments
being passed to Clang. The solution is to decide that that diagnostic
engine is a temporary one and to create a proper one later. (And if
this sounds like a lousy solution, I don't disagree, but it's what
Clang does too.)
rdar://problem/39197895 and possibly something older but I can't find it
The MSVC environment does not have a `-isysroot` or `-sysroot`
equivalent. Instead, manually expand the sysroot to the path as a
prefix to `/usr/include` and treat the path as a system include
directory. This fixes a number of tests which use `-sdk` on Windows.
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.
