- All parts of the compiler now use ‘P1 & P2’ syntax
- The demangler and AST printer wrap the composition in parens if it is
in a metatype lookup
- IRGen mangles compositions differently
- “protocol<>” is now “swift.Any”
- “protocol<_TP1P,_TP1Q>” is now “_TP1P&_TP1Q”
- Tests cases are updated and added to test the new syntax and mangling
The use of `std::make_tuple` requires the declaration of the function which is
provided by the C++ standard header `tuple`. This would get implicitly included
by one of the other C++ headers on the currently tested libraries, but does not
occur with the Microsoft C++ library. Add the missing include.
Rather than duplicating the constant value, use the `sizeof` operator to have
the value propogate from the static buffer allocation. Any standards conforming
implementation of `snprintf` will null-terminate the output unless the buffer is
NULL (a zero-sized buffer is passed to the call). On Windows, where this is not
the case, the function is named `_snprintf` which ensures that we do not
accidentally end up with the incorrect behaviour.
The general rule here is that something needs to be SWIFT_CC(swift)
if it's just declared in Swift code using _silgen_name, as opposed to
importing something via a header.
Of course, SWIFT_CC(swift) expands to nothing by default for now, and
I haven't made an effort yet to add the indirect-result / context
parameter ABI attributes. This is just a best-effort first pass.
I also took the opportunity to shift a few files to just implement
their shims header and to demote a few things to be private stdlib
interfaces.
I don't have a good way to test for leaking a box. Once I come up
with one, I will write a test for this patch as well as the earlier
patch "Runtime: Tweak Mirrors for resilience".
Fixes <rdar://problem/25797038>.
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.
