print and parse as a stable hexadecimal form that isn't interpreted as UTF8.
One use case is in representing serialized protobuf strings (as in the
tensorflow branch: f7ed452eba/lib/SILOptimizer/Mandatory/TFPartition.cpp (L3875)).
The original work was done by @lattner and merged into the tensorflow
branch. This PR is to upstream those changes.
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.
Rather than storing a mangled name in a Swift protocol descriptor,
which encodes information that is redundant with the context of the
protocol, store an unmangled name as in nominal type descriptors. Update
the various places where this name is used to extract the demangle
tree from the context descriptors.
Reimplement protocol descriptors for Swift protocols as a kind of
context descriptor, dropping the Objective-C protocol compatibility
layout. The new protocol descriptors have several advantages over the
current implementation:
* They drop all of the unused fields required for layout-compatibility
with Objective-C protocols.
* They encode the full requirement signature of the protocol. This
maintains more information about the protocol itself, including
(e.g.) correctly encoding superclass requirements.
* They fit within the general scheme of context descriptors, rather than
being their own thing, which allows us to share more code with
nominal type descriptors.
* They only use relative pointers, so they’re smaller and can be placed
in read-only memory
Implements rdar://problem/38815359.
For now, the accessors have been underscored as `_read` and `_modify`.
I'll prepare an evolution proposal for this feature which should allow
us to remove the underscores or, y'know, rename them to `purple` and
`lettuce`.
`_read` accessors do not make any effort yet to avoid copying the
value being yielded. I'll work on it in follow-up patches.
Opaque accesses to properties and subscripts defined with `_modify`
accessors will use an inefficient `materializeForSet` pattern that
materializes the value to a temporary instead of accessing it in-place.
That will be fixed by migrating to `modify` over `materializeForSet`,
which is next up after the `read` optimizations.
SIL ownership verification doesn't pass yet for the test cases here
because of a general fault in SILGen where borrows can outlive their
borrowed value due to being cleaned up on the general cleanup stack
when the borrowed value is cleaned up on the formal-access stack.
Michael, Andy, and I discussed various ways to fix this, but it seems
clear to me that it's not in any way specific to coroutine accesses.
rdar://35399664
In a generic requirement, distinguish between Swift and
Objective-C protocols using a spare bit within the relative
(indirectable) reference to the protocol.
Switch one entry point in the runtime (swift_getExistentialTypeMetadata)
to use ProtocolDescriptorRef rather than a protocol descriptor. Update
IRGen to produce ProtocolDescriptorRef instances for its calls, setting
the discriminator bit appropriately.
Within the runtime, verify that all instances of ProtocolDescriptorRef have
the right layout, i.e., the discriminator bit is set for @objc protocols
but not Swift protocols.
Summary:
There are a few problems with how Swift currently emits location
information for CodeView.
1. WinDbg does not work well with column information so all column
locations must be set to zero.
2. Some instructions, e.g., ``a + b``, will emit ``@llvm.trap()``
and ``unreachable``. Those instructions should have artificial
locations, i.e., they should have a line location of zero.
3. Some instructions, e.g., ``a / b``, will emit ``unreachable``
sandwiched between other code for that instruction. This makes
WinDbg confused and it cannot decide which set of instructions
to break on. Those instructions should have the same line location
as the others.
4. There are several prologue instructions with artificial line
locations that create breaks in the linetables. Those instructions
should have valid line locations, usually at the start of the
function.
5. Case bodies have cleanup instructions with artificial line
locations unless it has a ``do`` block. Those locations should
be the last line in the case block.
Test Plan:
test/DebugInfo/basic.swift
test/DebugInfo/columns.swift
test/DebugInfo/linetable-codeview.swift
test/DebugInfo/line-directive-codeview.swift
"@?" is not a method signature. An acceptable format is "vM@0:N", where
N is the pointer size and M is twice the pointer size. The numeric
values don't matter anymore on Apple platforms because the runtime does
not rely on them (they used to be stack offsets from the base pointer),
but given that the first (self) and second (_cmd) parameters are
pointers, the expected value is easily obtained and it is probably good
style to include it.
Fixes https://bugs.swift.org/browse/SR-8203
This disables inlinability of _stdlib_isOSVersionAtLeast. I don't see
value in making it inlinable as long as _swift_stdlib_operatingSystemVersion is
opaque.
rdar://41849700
When it comes to functions with tuple result types in
the LoadableByAddress pass, we do not intend to perform
relevant transformation, but somehow some implementation
is not right. This patch adds appropriate checks to correct
such transformation conditions.
Resolves: SR-8076.
