I am going to leave in the infrastructure around this just in case. But there is
no reason to keep this in the tests themselves. I can always just revert this
and I don't think merge conflicts are likely due to previous work I did around
the tooling for this.
We were hoping to use these to allow for plus_zero to be easily reverted. It
turns out that it took more tooling/time than we inticipated, so I am going back
to the old way of doing things. So remove the dead tests.
rdar://34222540
Update IRGen to trigger generation of type metadata for foreign
struct types found in fields. And fix TypeRefBuilder to handle
the case where struct has fields but at the same time has opaque
metadata.
Update IRGen to trigger generation of type metadata for foreign
struct types found in fields. And fix TypeRefBuilder to handle
the case where struct has fields but at the same time has opaque
metadata.
This makes them consistent no matter what shenanigans are pulled by
the importer, particularly NS_ENUM vs. NS_OPTIONS and NS_SWIFT_NAME.
The 'NSErrorDomain' API note /nearly/ works with this, but the
synthesized error struct is still mangled as a Swift declaration,
which means it's not rename-stable. See follow-up commits.
The main place where this still falls down is NS_STRING_ENUM: when
this is applied, a typedef is imported as a unique struct, but without
it it's just a typealias for the underlying type. There's also still a
problem with synthesized conformances, which have a module mangled
into the witness table symbol even though that symbol is linkonce_odr.
rdar://problem/31616162
TypeDecoder's interface with its builders already treated protocols as
a type (due to their being mangled as "protocol composition containing
one type"), and intermixed protocols with superclasses when forming
compositions. This makes for some awkwardness when working with
protocol descriptors, which are very much a distinct entity from a
type.
Separate out the notion of a "protocol declaration" (now represented
by the builder-provided BuiltProtocolDecl type) from "a protocol
composition containing a single type", similarly to the way we handle
nominal type declarations. Teach remote mirrors and remote AST to
handle the new contract.
Currently if function has a single parameter we'd skip mangling some of the
parameter flags e.g. `__shared`, `inout` still works because it's part of
the type itself (currently) but would be broken too if that were to change.
Currently when function types like `(_: Int...) -> Void` are mangled
their names are going to include enclosing sugar BoundGenericType(Array),
which is not necessary and doesn’t play well with `AnyFunctionType::Param`
which strips the sugar away.
Resolves: rdar://problem/34941557
@objc enums lower as their raw type, so should go through the same
code path as imported enums.
Fixes <https://bugs.swift.org/browse/SR-5625> and
<rdar://problem/33683103>.
This reverts commit 25985cb764. For now,
we're trying to avoid spurious non-structural changes to the mangling,
so that the /old/ mangling doesn't appear to change. That doesn't mean
no changes at all, but we can save this one for later.
The goal here is to make the short demangling as short and readable as possible, also at the cost of omitting some information.
The assumption is that whenever the short demangling is displayed, there is a way for the user to also get the full demangled name if needed.
*) omit <where ...> because it does not give useful information anyway
Deserializer.deserialize<A where ...> () throws -> [A]
--> Deserializer.deserialize<A> () throws -> [A]
*) for multiple specialized functions only emit a single “specialized”
specialized specialized Constructible.create(A.Element) -> Constructible<A>
--> specialized Constructible.create(A.Element) -> Constructible<A>
*) Don’t print function argument types:
foo(Int, Double, named: Int)
--> foo(_:_:named:)
This is a trade-off, because it can lead to ambiguity if there are overloads with different types.
*) make contexts of closures, local functions, etc. more readable by using “<a> in <b>” syntax
This is also done for the full and not only for the simplified demangling.
Renderer.(renderInlines([Inline]) -> String).(closure #1)
--> closure #1 in Renderer.renderInlines
*) change spacing, so that it matches our coding style:
foo <A> (x : A)
--> foo<A>(x: A)
We would run into an assertion during building the partial apply forwarding
thunk because we passed down a parameter convention of an empty argument
although we ignore it for the purpose of adding to the closure context.
However, the code path for the non-allocated closure context (0 or one capture)
would assert that there is only one convention.
Reconcile this by not adding the empty parameter to the convention array.
rdar://31487947
It also uses the new mangling for type names in meta-data (except for top-level non-generic classes).
lldb has now support for new mangled metadata type names.
This reinstates commit 21ba292943.
For this we are linking the new re-mangler instead of the old one into the swift runtime library.
Also we are linking the new de-mangling into the swift runtime library.
It also switches to the new mangling for class names of generic swift classes in the metadata.
Note that for non-generic class we still have to use the old mangling, because the ObjC runtime in the OS depends on it (it de-mangles the class names).
But names of generic classes are not handled by the ObjC runtime anyway, so there should be no problem to change the mangling for those.
The reason for this change is that it avoids linking the old re-mangler into the runtime library.
These tests fail because we incorrectly build some parts of the reflection
library with the swift-clang, and link it against code built with the
host-clang. ASAN doesn't support this.
Until we fix this, make sure we skip the tests only in ASAN builds, instead
of disabling them altogether.
Use a syntax that declares the layout's generic parameters and fields,
followed by the generic arguments to apply to the layout:
{ var Int, let String } // A concrete box layout with a mutable Int
// and immutable String field
<T, U> { var T, let U } <Int, String> // A generic box layout,
// applied to Int and String
// arguments
The alignment was set to 0, which messed up the record layout
computations. Add an assert to catch this in the future.
Fixes <rdar://problem/29115967>.
Previously we would crash if we couldn't look up an associated
type witness for a concrete type.
Instead, propagate the failure up to type lowering, which returns
nullptr to the caller, just like when other metadata is missing.
Pseudogeneric functions do not have runtime type metadata in
their closure context, so don't try to emit metadata sources
in the capture descriptor for reflection.
Also, erase generic type parameters in capture types down to
AnyObject, since the reflection library won't be able to
substitute them.
This affects the computed stride for fixed-sized types in IRGen as well as the stored stride in value witness tables.
The reason is to let comparisons and difference operations work for pointers to zero-sized types.
(Currently this is achieved by using Builtin.strideof_nonzero in MemoryLayout.stride, but this requires a std::max(1, stride) operation after loading the stride)
Ensure they get emitted at the end of the job by the dispatcher, and
also use a proper mangling and shared linkage for these symbols so
that if multiple threads emit the same descriptor it gets merged.
The new tests attempt to exercise these scenarios.
Fixes <rdar://problem/27906876>.
- If a parameter type is a sugared function type, mark the type
as non-escaping by default. Previously, we were only doing this
if the parameter type was written as a function type, with no
additional sugar.
This means in the following cases, the function parameter type
is now non-escaping:
func foo(f: ((Int) -> Void))
typealias Fn = (Int) -> Void
func foo(f: Fn)
- Also, allow @escaping to be used in the above cases:
func foo(f: @escaping ((Int) -> Void))
typealias Fn = (Int) -> Void
func foo(f: @escaping Fn)
- Diagnose usages of @escaping in inappropriate locations, instead
of just ignoring them.
It is unfortunate that sometimes we end up desugaring the typealias,
but currently there are other cases where this occurs too, such as
qualified lookpu of protocol typealiases with a concrete base
type, and generic type aliases. A more general representation for
sugared types (such as an AttributedType sugared type) would allow
us to solve this in a more satisfactory manner in the future.
However at the very least this patch factors out the common code
paths and adds comments, so it shouldn't be too bad going forward.
Note that this is a source-breaking change, both because @escaping
might need to be added to parameters with a sugared function type,
and @escaping might be removed if it appears somewhere where we
do not mark function types as non-escaping by default.
This allows us to freely pass the address of a variable of such
types to a C function without worrying about it overwriting other
things if e.g. it memcpy's sizeof(T) bytes and thus clobbers the
otherwise-non-existent tail padding.
There are ways to get this optimization back, but they require
things like materializing to a temporary instead of passing the
address directly. We haven't done that work yet, so we don't
get to take advantage of it.
rdar://26828018
