Remove the reference to String, which leaks internal implementation details,
check for invalid inputs, and make the API more flexible. Remove the similar
Swift API, since it provides no additional value.
The C++ code was very fragile in terms of ABI dependencies and broke
when the standard library was built with -enable-resilience.
The actual reason it broke is that case numbering changes when
resilience is enabled, but instead of messing with that, it seemed
more logical to rewrite this routine in Swift instead, to avoid
ABI dependencies altogether.
This requires using the "shadow protocol" trick to call NSNumber
methods, since we cannot import NSNumber from the stdlib.
Make _MagicMirrorData @_fixed_layout, but not the concrete mirror
implementations.
To make the calling convention work in resilient builds, make the
runtime entry points into top-level functions that take a
_MagicMirrorData, instead of adding @_silgen_name attributes on
methods.
This involves changing the convention on the 'owner' parameter
from +0 to +1.
Also, there was a memory leak in the old enum code that I noticed
by inspection. We would copy the enum value into a box, strip
the enum tag bits, take the box contents but never free the box
itself.
The fix isn't very satisfying either -- we have to modify the
source enum in-place to strip tag bits, then we copy it into a
box having the right payload type, and add the tag bits back.
At least this way, we can free the box after.
clang and gcc provide a preprocessor macro called `__USER_LABEL_PREFIX__` which
provides the user label prefix for the specific target that the translation unit
is being built for. Rather than trying to reconstruct the logic in place via
various checks, fallback to the compiler to provide this information. Although
this limits the compilers (MSVC does not provide this preprocessor macro
definition), the only supported compiler ATM is clang, and it has provided this
definition for some time now.
This addresses the FIXME that was associated with the user label prefix being
applied under specific cases.
NFC.
Similarly to how we've always handled parameter types, we
now recursively expand tuples in result types and separately
determine a result convention for each result.
The most important code-generation change here is that
indirect results are now returned separately from each
other and from any direct results. It is generally far
better, when receiving an indirect result, to receive it
as an independent result; the caller is much more likely
to be able to directly receive the result in the address
they want to initialize, rather than having to receive it
in temporary memory and then copy parts of it into the
target.
The most important conceptual change here that clients and
producers of SIL must be aware of is the new distinction
between a SILFunctionType's *parameters* and its *argument
list*. The former is just the formal parameters, derived
purely from the parameter types of the original function;
indirect results are no longer in this list. The latter
includes the indirect result arguments; as always, all
the indirect results strictly precede the parameters.
Apply instructions and entry block arguments follow the
argument list, not the parameter list.
A relatively minor change is that there can now be multiple
direct results, each with its own result convention.
This is a minor change because I've chosen to leave
return instructions as taking a single operand and
apply instructions as producing a single result; when
the type describes multiple results, they are implicitly
bound up in a tuple. It might make sense to split these
up and allow e.g. return instructions to take a list
of operands; however, it's not clear what to do on the
caller side, and this would be a major change that can
be separated out from this already over-large patch.
Unsurprisingly, the most invasive changes here are in
SILGen; this requires substantial reworking of both call
emission and reabstraction. It also proved important
to switch several SILGen operations over to work with
RValue instead of ManagedValue, since otherwise they
would be forced to spuriously "implode" buffers.
...and explicitly mark symbols we export, either for use by executables or for runtime-stdlib interaction. Until the stdlib supports resilience we have to allow programs to link to these SPI symbols.
This pull request broke the following tests on several build configurations
(eg --preset=buildbot,tools=RA,stdlib=DA)
1_stdlib/Reflection.swift
1_stdlib/ReflectionHashing.swift
1_stdlib/UnsafePointer.swift.gyb
This reverts commit c223a3bf06, reversing
changes made to 5c2bb09b09.
Changes:
- Reverted commit reverting original SR-88 commit
- Removed mirror children helper collections and related code
- Rewrote some tests to keep them working properly
- Wrote two more tests for the three pointer APIs to ensure no crashes if created using a value > Int64.max
This reverts commit 8917eb0e5a.
Recent changes added support for resiliently-sized enums, and
enums resilient to changes in implementation strategy.
This patch adds resilient case numbering, fixing the problem
where adding new payload cases would break existing code by
changing the numbering of no-payload cases.
The problem is that internally, enum cases are numbered with payload
cases coming first, followed by no-payload cases. While each list
is itself in declaration order, with new additions coming at the
end, we need to partition it to give us a fast runtime test for
"is this a payload or no-payload case index."
The resilient numbering strategy used here is that the getEnumTag
and destructiveInjectEnumTag value witness functions now take a
tag index in the range [-ElementsWithPayload..ElementsWithNoPayload-1].
Payload elements are numbered in *reverse* declaration order, so
adding new payload cases yields decreasing tag indices, and adding
new no-payload cases yields increasing tag indices, allowing use
sites to be resilient.
This adds the adjustment between 'fragile' and 'resilient' tag
indices in a somewhat unsatisfying manner, because the calculation
could be pushed down further into EnumImplStrategy, simplifying
both the IRGen code and the generated IR. I'll clean this up later.
In the meantime, clean up some other stuff in GenEnum.cpp, mostly
abstracting code that walks cases.
Jira: SR-88
Changes:
- Removed stdlib type conformances to _Reflectable
- Conformed stdlib types to CustomReflectable, CustomPlaygroundQuickLookable
- Rewrote dump() function to not use _reflect()
- CGRect, CGPoint, CGSize now conform to CustomDebugStringConvertible
- Rewrote unit tests for compatibility with new API
Reuses the enum metadata layout and builder because most of the logic is
also required for Optional (generic arg and payload). We may want to
optimize this at some point (Optional doesn't have a Parent), but I
don't see much opportunity.
Note that with this approach there will be no change in metadata layout.
Changing the kind still breaks the ABI of course.
Also leaves the MirrorData summary string as "(Enum Value)". We should
consider changing it.
Getting the name of a type seems like reasonable core runtime functionality, and something the runtime can cache on its side too. Have the function return a pointer to a raw string in memory owned by the runtime, and have it be wrappen in a Swift.String on the standard library side.
We don't really need its peculiar behavior characteristics; its uses in the legacy mirror implementations can now be replaced by direct stringification of metatypes.
Set up a separate libSwiftStubs.a archive for C++ stub functionality that's needed by the standard library but not part of the core runtime interface. Seed it with the Stubs.cpp and LibcShims.cpp files, which consist only of stubs, though a few stubs are still strewn across the runtime code base.
'Ss' appears in manglings tens of thousands of times in the standard library and is also incredibly frequent in other modules. This alone is enough to shrink the standard library by 59KB.
Swift SVN r32409
