Use the generic type lowering algorithm described in
"docs/CallingConvention.rst#physical-lowering" to map from IRGen's explosion
type to the type expected by the ABI.
Change IRGen to use the swift calling convention (swiftcc) for native swift
functions.
Use the 'swiftself' attribute on self parameters and for closures contexts.
Use the 'swifterror' parameter for swift error parameters.
Change functions in the runtime that are called as native swift functions to use
the swift calling convention.
rdar://19978563
For a value of an opaque generic type `<T> x: T`, the language currently defines `type(of: x)` and `T.self` as both producing a type `T.Type`, and the result of substituting an existential type by `T == P` gives `P.Protocol`, so the `type(of:)` operation on `x` can only give the concrete protocol metatype when `x` is an existential in this case. The optimizer understood this rule, but the runtime did not, causing SR-3304.
Correct behavior with resilience requires calling accessors instead
of using the metadata symbols directly.
For some reason this file gets linked in with SwiftRuntimeTests too,
so make the types @_versioned in the stdlib.
Fixes <rdar://problem/29213794>.
When getting a mirror child that is a class existential, there
may be witness tables for the protocol composition to copy. Don't
just take the address of a class instance pointer from the stack -
make a temporary existential-like before calling into the Mirror
constructor.
This now correctly covers reflecting weak optional class types, and weak
optional class existential types, along with fixing a stack buffer
overflow reported by the Address Sanitizer (thanks, ASan!).
Tests were also updated to check for the validity of the child's data.
rdar://problem/27348445
Heap boxes don't have a "class" metadata kind, so make
sure to release them when creating a new owner for loading
weak references in the runtime mirrors.
rdar://problem/27348445
for weak semantics, that is!
94a9c512b9 made some changes to loading
weak references by adding some information in the lower bits with
respect to locking. These bits need to be masked out when performing a
load, such as when we want to get the metadata pointer for a class
instance. This normally works fine when going through the normal weak
loading functions in the runtime.
When the runtime function swift_ClassMirror_subscript gets the offset of
one of its stored properties, it immediately packages it into the the
ad-hoc existential container, known as just `Mirror` in the runtime.
However, the weak reference isn't aligned! It has bit 1 set. We weren't
loading the weak reference here as we would during normal SILGen, such
as with a weak_load instruction. Simulate that here and make the
reference strong before putting it into the Mirror container, which also
clears those lower bits.
rdar://problem/27475034
There are still a couple of other cases to handle, namely the
unowned(safe) and unowned(unsafe) reference kinds. There may be other
places where an unaligned pointer is problematic in the runtime, which
we should audit for correctness.
rdar://problem/27809991
- 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.
