Partially reverts f4f8349 (from July!) which caused us to start
importing global blocks with unbridged parameters, breaking source
compatibility. I'm still investigating whether there's an actual hole
in the logic; see next few commits.
rdar://problem/34913634
Typedefs tend to be imported without bridging the underlying
type. However, when a typedef is used within a bridging context, we
should bridge based on the underlying type. That wasn't being done
consistently, causing us to import various typedefs without bridging
at all. Update the logic to use the bridged underlying type whenever
the (often unbridged) typedef type itself doesn't line up.
Fixes rdar://problem/34913507.
We just import this as a property, and Swift doesn't support
properties with dynamic Self type, even if they are read-only. Don't
mark the getter as returning dynamic Self in this case.
(This was only a problem in builds with the AST verifier turned on.)
https://bugs.swift.org/browse/SR-5684
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
Now that the GenericSignatureBuilder is no longer sensitive to the input
module, stop uniquing the canonical GSBs based on that module. The main
win here is when deserializing a generic environment: we would end up
creating a canonical GSB in the module we deserialized and another
canonical GSB in the module in which it is used.
Implement a module-agnostic conformance lookup operation within the GSB
itself, so it does not need to be supplied by the code constructing the
generic signature builder. This makes the generic signature builder
(closer to) being module-agnostic.
This has been showing up as nondeterministic failures on our Linux
bots in the clang_builtins.swift test, because that test used to
trigger typo correction! Which pulled in macros, which happened to
include some redefinitions, which resulted in this.
rdar://problem/34266952
We don't want to show "included from <bridging-header>" to the user--
that's just not helpful--but we /do/ want to see any unexpected
diagnostics that happen to be reported in the importer's synthetic
buffers. This would have helped us track down rdar://problem/34664596
much sooner.
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
Once we compute a generic signature from a generic signature builder,
all queries involving that generic signature will go through a separate
(canonicalized) builder, and the original builder can no longer be used.
The canonicalization process then creates a new, effectively identical
generic signature builder. How silly.
Once we’ve computed the signature of a generic signature builder, “register”
it with the ASTContext, allowing us to move the existing generic signature
builder into place as the canonical generic signature builder. The builder
requires minimal patching but is otherwise fully usable.
Thanks to Slava Pestov for the idea!
Funnel all places where we create a generic signature builder to compute
the generic signature through a single entry point in the GSB
(`computeGenericSignature()`), and make `finalize` and `getGenericSignature`
private so no new uses crop up.
Tighten up the signature of `computeGenericSignature()` so it only works on
GSB rvalues, and ensure that all clients consider the GSB dead after that
point by clearing out the internal representation of the GSB.
