When a (file)private entity occurs inside a generic context, we still need
information about the genericity of the enclosing context to demangle
to metadata. Emit complete context descriptors for parents of anonymous
contexts.
Fixes rdar://problem/46109026.
This reverts commit 121f5b64be.
Sorry to revert this again. This commit makes some pretty big changes. After
messing with the merge-conflict created by this internally, I did not feel
comfortable landing this now. I talked with Saleem and he agreed with me that
this was the right thing to do.
A dynamically replaceable function calls through a global variable that
holds the function pointer.
struct ChainEntry {
void *(funPtr)();
struct ChainEntry *next;
}
ChainEntry dynamicallyReplaceableVar;
void dynamicallyReplaceableFunction() {
dynamicallyReplaceableVar.funPtr()
}
dynamic replacements will be chainable so the global variable also
functions as the root entry in the chain of replacements.
A dynamic replacement functions can call the previous implementation by
going through its chain entry.
ChainEntry chainEntryOf_dynamic_replacement_for_foo;
void dynamic_replacement_for_foo() {
// call the previous (original) implementation.
chainEntryOf_dynamic_replacement_for_foo.funPtr();
}
Change the retroactive conformance mangling to use the new
any-protocol-conformance mangling, which maintains more information about
concrete conformances. Specifically, it maintains conformance information
for conditional requirements. It also uses the protocol-conformance-ref
production that will eventually allow symbolic references to protocol
conformance descriptors.
While here, extend the “is retroactive” check during mangling to look for
retroactive conformances in the conditional requirements of a conformance.
The immediate conformance might not be retroactive, but its specialization
might depend on a retroactive conformance. Mangle these as “retroactive”, so
we can correctly reconstruct the exact type.
Introduce complete mangling for references to protocol conformances:
* Mangle requirements of conditional conformances when present.
* Mangle conformance access paths for generic environment-dependent
conformances.
* Abstract protocol conformance references so we can introduce
symbolic references for them.
The key thing here is that all of the underlying code is exactly the same. I
purposely did not debride anything. This is to ensure that I am not touching too
much and increasing the probability of weird errors from occurring. Thus the
exact same code should be executed... just the routing changed.
We were strangely excluding protocols from being symbolically referenced
in the any-generic-type production, which meant that we could not resolve
(e.g.) associated type references to private protocols at runtime. Allow
protocol symbolic references in this position, and cope with it in the
demangler.
Fixes the rest of rdar://problem/44977236.
Extending the mangling of symbolic references to also include indirect
symbolic references. This allows mangled names to refer to context
descriptors (both type and protocol) not in the current source file.
For now, only permit indirect symbolic references within the current module,
because remote mirrors (among other things) is unable to handle relocations.
Co-authored-by: Joe Groff <jgroff@apple.com>
The mangling of associated type paths was only adding the names of
associated types, and not their enclosing protocols. This led to mangling
collisions that could lead to corrupted metadata. In the standard
library, for example, the generic requirements for the
Unicode _ParsingIterator in the standard library ended up encoding an
access to Sequence.Element rather than IteratorProtocol.Element due
to the mangling conflict.
Part of SR-7553 / rdar://problem/39769906.
This function can be queried to find out whether the passed
mangled name is an Objective-C symbol. This will be used
in the debugger to replace an hardcoded check that would
break if the mangling prefix changed.
<rdar://problem/44467875>
Default associated conformance accessors will be used in default
witness tables to fill in associated conformances for defaulted
associated types. Add (de|re|)mangling support for them and make them
linking entities in IRGen.
Associated conformance descriptors are aliases that refer to associated
conformance requirements within a protocol descriptor’s list of
requirements. They will be used to provide protocol resilience against
the addition of new associated conformance requirements (which only makes
sense for newly-introduced, defaulted associated types).
When an associated type witness has a default, record that as part of
the protocol and emit a default associated type metadata accessor into the
default witness table. This allows a defaulted associated type to be
added to a protocol resiliently.
This is another part of rdar://problem/44167982, but it’s still very
limiting because the new associated type cannot have any conformances.
Introduce an alias that refers one element prior to the start of a
protocol descriptor’s protocol requirements. This can be subtracted from
an associated type descriptor address to determine the offset of the
associated type accessor within a corresponding witness table. The code
generation for the latter is not yet implemented.
Avoid a dependency on LLVMSupport at runtime through the `llvm_unreachable`.
This would pull in `llvm_unreachable_internal` in debug builds, which requires a
runtime dependency on LLVMSupport which increases the size of the binary
considerably.
For example:
public struct Mystruct<T> {
func testit<U>(x: T, u: U) {
typealias Myalias = AnyObject
}
}
In this case the Myalias has a generic function as context.
Since this library uses ADT headers, it will pull in a dependency for
LLVMSupport (Error.cpp has the necessary variable declaration for ABI breaking
checks). Disable the ABI breaking check validation as we only use the library
for header-only dependencies. Avoiding this dependency shaves nearly 900 KiB
from the resultant binary.
This patch adds SIL-level debug info support for variables whose
static type is rewritten by an optimizer transformation. When a
function is (generic-)specialized or inlined, the static types of
inlined variables my change as they are remapped into the generic
environment of the inlined call site. With this patch all inlined
SILDebugScopes that point to functions with a generic signature are
recursively rewritten to point to clones of the original function with
new unique mangled names. The new mangled names consist of the old
mangled names plus the new substituions, similar (or exactly,
respectively) to how generic specialization is handled.
On libSwiftCore.dylib (x86_64), this yields a 17% increase in unique
source vars and a ~24% increase in variables with a debug location.
rdar://problem/28859432
rdar://problem/34526036
The central thrust of this patch is to get these metadata initializations
off of `swift_once` and onto the metadata-request system where we can
properly detect and resolve dependencies. We do this by first introducing
runtime support for resolving metadata requests for "in-place"
initializations (committed previously) and then teaching IRGen to actually
generate code to use them (this patch).
A non-trivial amount of this patch is just renaming and refactoring some of
existing infrastructure that was being used for in-place initializations to
try to avoid unnecessary confusion.
The remaining cases that are still using `swift_once` resolution of
metadata initialization are:
- non-generic classes that can't statically fill their superclass or
have resilient internal layout
- foreign type metadata
Classes require more work because I'd like to switch at least the
resilient-superclass case over to using a pattern much more like what
we do with generic class instantiation. That is, I'd like in-place
initialization to be reserved for classes that actually don't need
relocation.
Foreign metadata should also be updated to the request/dependency scheme
before we declare ABI stability. I'm not sure why foreign metadata
would ever require a type to be resolved, but let's assume it's possible.
Fixes part of SR-7876.
