Previously it was not possible to parse expressions of the form
[Int -> Int]()
because no Expr could represent the '->' token and be converted later
into a FunctionTypeRepr. This commit introduces ArrowExpr which exists
solely to be converted to FunctionTypeRepr later by simplifyTypeExpr.
https://bugs.swift.org/browse/SR-502
With a TypeLoc, we have a chance to offer diagnostics or even fix-its
to the contextual type, even though it's not represented by an
expression in the constraint system. This commit mostly just passes it
through, without attempting to use it anywhere or even pass a real
TypeLoc (with a valid TypeRepr).
(It does drop the contextual type parameter from
typeCheckExpressionShallow, since there were zero callers using it.)
No functionality change...yet.
Implements SE-0055: https://github.com/apple/swift-evolution/blob/master/proposals/0055-optional-unsafe-pointers.md
- Add NULL as an extra inhabitant of Builtin.RawPointer (currently
hardcoded to 0 rather than being target-dependent).
- Import non-object pointers as Optional/IUO when nullable/null_unspecified
(like everything else).
- Change the type checker's *-to-pointer conversions to handle a layer of
optional.
- Use 'AutoreleasingUnsafeMutablePointer<NSError?>?' as the type of error
parameters exported to Objective-C.
- Drop NilLiteralConvertible conformance for all pointer types.
- Update the standard library and then all the tests.
I've decided to leave this commit only updating existing tests; any new
tests will come in the following commits. (That may mean some additional
implementation work to follow.)
The other major piece that's missing here is migration. I'm hoping we get
a lot of that with Swift 1.1's work for optional object references, but
I still need to investigate.
In the following code example, compiler emits an error of "cannot express tuple conversion...". However,
this is trivially fixable by adding multiple labels in the tuple pattern of the for-each statement. This
commit adds such fixit.
func foo(array : [(some: Int, (key: Int, value: String))]) {
for (i, (k, v)) in array {
}
}
Arguably, this code should not be run in invalid cases,
but that seems difficult to enforce given the numnber of paths
through the type-checker. It's better to simply be more
conservative here.
a generic function type during constraint solving, as opposed to
checking a bunch of implicit things that we already know. This
should significantly improve the efficiency of checking uses of
generic APIs by reducing the total number of type variables and
constraints.
It is becoming increasingly funny to refer to this minimized generic
signature as the "mangling" signature.
The test changes are kind of a wash: in one case, we've eliminated
a confusing extra error, but in another we've caused the confusing
extra error to refer to '<<error type>>'. Not worth fighting right
now. The reference-dependencies change is due to not needing to
pull in all of those associated types anymore, which seems correct.
Right now, the rule is that any access of a stored property from a
constructor or destructor through 'self' must go directly to storage,
skipping observers or getter/setter overrides.
This means that in particular, constructors of resilient types cannot
be @_transparent, or defined in an extension in another module.
Previously, this was only caught in IRGen when the @_transparent
function was inlined into a function from another module, which made
debugging difficult.
Now, we hit an assert in Sema in this case. Of course it should be a
diagnostic; we'll get there eventually.
We could partially lift the restriction, allowing convenience
initializers to be defined @_transparent or be added in extensions,
by having accesses of stored properties from convenience inits go
through accessors. This would be safe, because at that point, we must
already have performed a self.init() delegation, however it would
potentially break existing code in subtle ways.
Also, this patch marks the RangeIterator and Range types @_fixed_layout,
since they define @_transparent initializers and this tripped the
new assert. Furthermore, note that the @_transparent initializer
must be versioned because it is inlined into another versioned
@_transparent function.
Extend the use of
_ObjectiveCBridgeable._unconditionallyBridgeFromObjectiveC to all
bridged types rather than using the custom entry points. Note that
there is a lot of hackery around ensuring that the conformance is
correct, because Sema needs to anticipate that SILGen (or later SIL
passes) might need those conformances. This primarily affects the
overlays, but with generalized bridging that means any mixed
Objective-C/Swift framework with bridged types.
This reverts commit 052d2d0a69.
The only actual issue with the original change was a missing change to
the UIApplicationMain SILGen test, which needs to build SILGen
overlays to execute properly; -enable-source-import doesn't suffice.
Introduce a new entrypoint to _ObjectiveCBridgeable,
_unconditionallyBridgeFromObjectiveC, which handles unconditional
bridging from an optional Objective-C object (e.g., an NSString) to
its bridged Swift type. Use it in SILGen to perform NSString -> String
bridging rather than the custom entry point.
Another small step toward generalized bridging.
In member ref expressions, if the base is optional, and the expected
expression result is either optional or unknown, suggest a fixit that
makes it into an optional chain expr rather than force unwrapping.
Since in many cases the actual fixit is emitted during diagnosis, and
thus, while type checking sub exprs with no contextual type specified
(so nothing to check for preferring optionality), we also need an
additional flag to pass down from FailureDiagnosis for whether we
prefer to fix as force unwrapping or optional chaining.
I attempted to do this same job via providing a convert type but
setting the ConvertTypeIsOnlyAHint flag on the type checker, but
unfortunately there are a lot of other moving parts that look at that
type, even if it is only supposed to be a hint, so an additional flag
to the CS ended up being cleaner.
We had four duplicated implementations of checking how a protocol
requirement uses 'Self', all slightly wrong or incomplete:
- When deciding if the protocol type can be used as an existential.
This one would just ignore 'Self' in the return type of a method
completely, which was incorrect for cases where 'Self' is
contravariant but part of the return value, for example:
func foo() -> (Self -> ())
- When deciding if a member access can be performed on an existential
value. This is distinct from the former, because the member may
have been defined in a protocol extension, in which case it cannot
be used even if the protocol type can be used as an existential.
Unfortunately, this implementation was overly conservative, and
would reject uses of 'Self' where Sema could in fact erase the
existential type, for example:
func foo() -> Self??
func foo() -> Self.Type
func foo() -> (Self, Self)
This function handled function return types correctly, effectively
plugging the leak in the previous code. It did lead to inconsistent
behavior with protocols that had contravariant Self in requirements
though; sometimes we would diagnose uses of the existential type,
other times we would only complain about specific members.
- When deciding if a method in a non-final class can model a protocol
requirement. This one was the most elaborate one, but here
contravariance and uses of associated types are actually okay, so
it was written to pick up covariant 'Self' only. However, it also
did not handle metatypes and tuples.
- When opening the type of member of an existential, we would check
if the return value was 'Self' or an optional of 'Self', but again
this check was too conservative, so after the previous three were
fixed, we could reference members on existentials that did not
have a correct opened type.
Now, these have been combined into one check. To fix some crashes,
Sema's implementation of erasing existentials now relies on
coerceToType() instead of hand-rolling a few coercions of its own,
and wrapping the rest in CovariantFunctionConversionExpr, which
didn't make much sense if the result was not a function type.
SILGen still does not support function type conversions where an
existential return value is being erased; these would silently
miscompile before, but crash with an assertion now, because they
are correctly modeled as a FunctionConversionExpr, and not
CovariantFunctionConversionExpr.
This reorganization allows adding attributes that refer to types.
I need this for a @_specialize attribute with a type list.
PrintOptions.h and other headers depend on these enums. But Attr.h
defines a lot of classes that almost never need to be included.
My previous commit here didn’t work correctly for nested tuples, both
because it didn’t recurse into them to propagate access kind correctly
and because an outer TupleIndex overload (when indexing into the nested
tuple) could still be expecting an lvalue type.
This fix is much better. ConstraintSystem::resolveOverload now
correctly always expects rvalue types from rvalue tuples. And during
applyMemberRefExpr, if the overload expects an rvalue but the tuple
contains lvalues, coerceToType() correctly does any recursive munging
of the tuple expr required.
The issue here is that the constraint solver was deciding on
FixKind::RelabelCallTuple as the fix for the problem and emitting the
diagnostic, even though there were two different fixes possible.
CSDiags has the infrastructure to support doing doing the right thing
here, but is only being used for ApplyExprs, not SubscriptExprs.
The solution is to fix both problems: remove FixKind::RelabelCallTuple,
to let CSDiags handle the problem, and enhance CSDiags to treat
SubscriptExpr more commonly with ApplyExpr. This improves several cases
where the solver was picking one solution randomly and suggesting that
as a fix, instead of listing that there are multiple different solutions.
There's a group of methods in `DeclContext` with names that start with *is*,
such as `isClassOrClassExtensionContext()`. These names suggests a boolean
return value, while the methods actually return a type declaration. This
patch replaces the *is* prefix with *getAs* to better reflect their interface.
_BridgedNSError conformances can affect the runtime behavior of
dynamic casts (e.g. 'is'). Unfortunately, the conformance is not
always emitted, in an effort to save space when not used. This change
forces the conformance witness tables to be emitted when we can detect
a dynamic cast to an _BridgedNSError conforming enum.
Test cases included, as well as a note about a potentially erroneous
path that is not currently handled: when the dynamic cast occurs in a
generic function to a generic type (and thus we are unsure which
conformances we need to pull in).
