Bitwise takability is now part of the layout of a type, because
non-bitwise takable types are never stored inline in an
existential or resilient global's buffer, even if they would
fit.
The basic rule is that weak references, unknown-refcounted
unowned references, and aggregates that contain them, are not
bitwise takable, whereas everything else is bitwise takable.
Also, since the bitwise takable for an unowned reference
depends on the reference counting style, we have to record the
superclass of a protocol, if any, to correctly determine the
reference counting style of the protocol existential.
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>.
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.
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.
One last bit of SE-0072. We shouldn't fall back to bridged classes in the absence of type context for literals anymore. By itself, this kind of hoses the use of literals with NS types, but I think we can get most of the QoI back with overlay changes I plan to propose following this.
This flips the switch to have @noescape be the default semantics for
function types in argument positions, for everything except property
setters. Property setters are naturally escaping, so they keep their
escaping-by-default behavior.
Adds contentual printing, and updates the test cases.
There is some further (non-source-breaking) work to be done for
SE-0103:
- We need the withoutActuallyEscaping function
- Improve diagnostics and QoI to at least @noescape's standards
- Deprecate / drop @noescape, right now we allow it
- Update internal code completion printing to be contextual
- Add more tests to explore tricky corner cases
- Small regressions in fixits in attr/attr_availability.swift
Also adds:
- Any is caught before doing an unconstrained lookup, and the
protocol<> type is emitted
- composition expressions can be handled by
`PreCheckExpression::simplifyTypeExpr` to so you can do lookups like (P
& Q).self
- Fixits corrected & new tests added
- Typeref lowering cases should have been optional
- This fixes a failing test case.
This commit defines the ‘Any’ keyword, implements parsing for composing
types with an infix ‘&’, and provides a fixit to convert ‘protocol<>’
- Updated tests & stdlib for new composition syntax
- Provide errors when compositions used in inheritance.
Any is treated as a contextual keyword. The name ‘Any’
is used emit the empty composition type. We have to
stop user declaring top level types spelled ‘Any’ too.
The approach here is to split this into two cases:
- If all case payloads have a fixed size, spare bits may be
potentially used to differentiate between cases, and the
remote reflection library does not have enough information to
compute the layout itself.
However, the total size must be fixed, so IRGen just emits a
builtin type descriptor (which I need to rename to 'fixed type
descriptor' since these are also used for imported value types,
and now, certain enums).
- If at least one case has a size that depends on a generic
parameter or is a resilient type, IRGen does not know the size,
but this means fancy tricks with spare bits cannot be used either.
The remote reflection library uses the same approach as the
runtime, basically taking the maximum of the payload size and
alignment, and adding a tag byte.
As with single-payload enums, we produce a new kind of
RecordTypeInfo, this time with a field for every enum case.
All cases start at offset zero (but of course this might change,
if for example we put the enum tag before the address point).
Also, just as with single-payload enums, there is no remote
'project case index' operation on ReflectionContext yet.
So the the main benefit from this change is that we don't entirely
give up when doing layout of class instances containing enums;
however, tools still cannot look inside the enum values themselves,
except in the simplest cases involving optionals.
Notably, the remote reflection library finally understands all
of the standard library's collection types -- Array, Character,
Dictionary, Set, and String.
I noticed even with multi-payload enum layout working, remote
reflection could not understand Set and Dictionary, because of
issues with Objective-C protocols in the standard library that
are used in the representation of those types.
The problem is that we were taking a different code path and
not emitting a field descriptor. A field descriptor is necessary
to differentiate Objective-C, class-bound and opaque protocols
from each other, so that existentials can use the correct
representation.
Attempt to lay out single-payload enums, using knowledge of extra
inhabitants where possible.
- The extra inhabitants of an aggregate are the extra inhabitants of
the first field. If the first field is empty, there are no extra
inhabitants, and subsequent fields do not affect anything.
- Function pointers and metatypes have different extra inhabitants
than Builtin.RawPointer, so have IRGen emit distinct builtin type
descriptors for those.
- Opaque existentials do not have extra inhabitants.
- Weak references do not have extra inhabitants.
Also, fix IRGen to emit more accurate enum reflection metadata in
these two cases:
- We now record whether enum cases are indirect or not. An indirect
case is the same as a payload case with Builtin.NativeObject.
- We now record whether a case is empty or not using the same logic
as the rest of IRGen. Previously, we would incorrectly emit a
payload type for a case with a payload that is an empty struct,
for example.
At this point we don't have a way to get the currently inhabited
enum case from a value. However, this is still an improvement because
we can still reflect other fields of aggregates containing enums,
instead of just giving up.
Finally make some methods on TypeCoverter private, and use 'friend'
to allow them to be accessed from other internal classes, making the
public API simpler.
Go through some pains to ensure that we emit an override for
the default initializer, since otherwise we emit a fatalError()
call which ends up creating some closures.
The exact order of the closures changed between master and
swift-3.0-preview-1-branch. It is better not to test this
part at all.
When we encounter a protocol typeref, we have to know if its @objc,
class-bound, or opaque, so make sure we provide the necessary
information when imported protocols are referenced.
Previously we would emit both a builtin descriptor and field
descriptor for imported classes, but we only need the latter.
Untangle some code and fix a crash with imported Objective-C
generics in the process.
Fixes <rdar://problem/26498484>.
- Lower Objective-C class typerefs as strong references with unknown
reference counting.
- Lower other imported C types as builtin blobs of their known
size, alignment, etc.
In the future, it might be beneficial to track which stored properties
of imported types are pointers, for better conservative scanning of
outgoing pointers to the heap.
rdar://problem/26240258
rdar://problem/26240394
The thin vs thick distinction is handled a little awkwardly. Instead of
passing around abstraction patterns, we add a "must be thick" bit to
MetatypeTypeRef, and thicken substitutions (to handle T; T := C.Type)
and the result of a subtitution (to handle T.Type; T := C).
With the exception of enums this completes <rdar://problem/25738849>.
Also add slightly inaccurate lowering for the special case of an
optional of a reference type. I need to rethink the approach for
extra inhabitants and enums, but this suffices for now.
Now that we can parse and substitute typerefs, and look up field
types, we finally have enough infrastructure in place to do some
basic layout of struct and tuple types from within the Reflection
library.
To facilitate testing, swift-reflection-dump now accepts multiple
-binary-filename flags, allowing types defined in the standard
library to be looked up.
More detailed end-to-end tests will come once I finish the
typeref-to-metadata builder.
Previously we would pre-process the same input files in the ObjC
and non-ObjC tests. This made the tests difficult to update because
the output of one was a subset of the other, and only one of the
two tests would run on any given platform.
Instead, let's just put the Objective-C tests in their own test
and input files.
When creating a TypeRef from metadata, we have a parent pointer
handy, and construct the TypeRef directly, so there's no need
to mutate the TypeRef after the fact.
When demangling a TypeRef from a string, the mangling encodes
the parent module or type context, so we can set it when
constructing the TypeRef there too.
Just drop labels when demangling TypeRefs. This is OK for now
since labels do not affect layout.
Vararg tuple types cannot appear directly as the type of
storage, however they can appear in function input types, and
therefore must be minimally supported. Since we don't plan on
doing function call reflection just yet, this doesn't matter
for now, but again we need to not crash.
With this patch, all TypeRefs in the Swift standard library now
successfully demangle and print.
These likely don't have Swift type metadata but might be useful to
record or instantiate based on what kind of metadata is encountered for
the sake of memory tools.
