Fixes a regression introduced with https://github.com/apple/swift/pull/68216.
Some nominal types belonging to clang modules don't have a clang node in the
AST, so make sure we match the logic used when computing IR linkage to
determine whether a nominal type is a clang type.
Resolves rdar://115308770
When a top-level decl is marked with @_originallyDefinedIn, some of its members
may also be newly added after the top-level decl has been moved to the current module.
For these members, we don't need emit $ld$previous$ symbols for them.
rdar://60478650
Using the new linker directives $ld$previous requires the compiler to know the previous
install names for the symbols marked as removed. This patch teaches the compiler
to take a path to a Json file specifying the map between module names and previous
install names. Also, these install names can be platform-specific.
Progress towards: rdar://58281536
The linker expects to see mangled symbols in the TBD, otherwise it won't
be able to link anything. Use LLVM's mangler to mangle them.
Fixes rdar://54055049
This checks that all combinations of optimized & non-optimized, and whole-module
optimization & incremental compilation give the same result, on a module where
this is actually interesting (i.e. has multiple files so the behaviour differs
between the two).
We need to be looking at the linkage of the witness, but mangling the
requirement. Also, getGetter() gets the getter, not the setter (copy-paste
strikes again).
Fixes rdar://problem/40355657.
The goal here is to make the short demangling as short and readable as possible, also at the cost of omitting some information.
The assumption is that whenever the short demangling is displayed, there is a way for the user to also get the full demangled name if needed.
*) omit <where ...> because it does not give useful information anyway
Deserializer.deserialize<A where ...> () throws -> [A]
--> Deserializer.deserialize<A> () throws -> [A]
*) for multiple specialized functions only emit a single “specialized”
specialized specialized Constructible.create(A.Element) -> Constructible<A>
--> specialized Constructible.create(A.Element) -> Constructible<A>
*) Don’t print function argument types:
foo(Int, Double, named: Int)
--> foo(_:_:named:)
This is a trade-off, because it can lead to ambiguity if there are overloads with different types.
*) make contexts of closures, local functions, etc. more readable by using “<a> in <b>” syntax
This is also done for the full and not only for the simplified demangling.
Renderer.(renderInlines([Inline]) -> String).(closure #1)
--> closure #1 in Renderer.renderInlines
*) change spacing, so that it matches our coding style:
foo <A> (x : A)
--> foo<A>(x: A)
We used to give witness thunks public linkage if the
conforming type and the protocol are public.
This is completely unnecessary. If the conformance is
fragile, the thunk should be [shared] [serialized],
allowing the thunk to be serialized into callers after
devirtualization.
Otherwise for private protocols or resilient modules,
witness thunks can just always be private.
This should reduce the size of compiled binaries.
There are two other mildly interesting consequences:
1) In the bridged cast tests, we now inline the witness
thunks from the bridgeable conformances, which removes
one level of indirection.
2) This uncovered a flaw in our accessibility checking
model. Usually, we reject a witness that is less
visible than the protocol; however, we fail to
reject it in the case that it comes from an
extension.
This is because members of an extension can be
declared 'public' even if the extended type is not
public, and it appears that in this case the 'public'
keyword has no effect.
I would prefer it if a) 'public' generated a warning
here, and b) the conformance also generated a warning.
In Swift 4 mode, we could then make this kind of
sillyness into an error. But for now, live with the
broken behavior, and add a test to exercise it to ensure
we don't crash.
There are other places where this "allow public but
ignore it, kinda, except respect it in some places"
behavior causes problems. I don't know if it was intentional
or just emergent behavior from general messiness in Sema.
3) In the TBD code, there is one less 'failure' because now
that witness thunks are no longer public, TBDGen does not
need to reason about them (except for the case #2 above,
which will probably require a similar workaround in TBDGen
as what I put into SILGen).
