Per the discussion in SR-1612, we don’t have a robust mechanism for
checking this and should warn about it.
Signed-off-by: Robert Widmann <devteam.codafi@gmail.com>
Whenever we have a call, retrieve the argument labels from the
argument structurally and associate them with the callee. We were
previously doing this as a separate AST walk (which was unnecessary),
so fold that into constraint generation for a CallExpr. We were also
allowing weird ASTs to effectively disable this information: tighten
that up and require that CallExprs always have a ParenExpr, TupleExpr,
or (as a temporary hack) a TypeExpr whose representation is a
TupleTypeRepr as their argument prior to type checking. This gives us
a more sane AST to work with, and guarantees that we aren't losing
label information.
From the user perspective, this should be NFC, because it's mostly AST
cleanup and staging.
The following diagnostics have been added:
1. implicit capture of inout arguments by closure literals that may escape (
not mark by @noescape) is now invalid. This also includes implicit capture
of `self`.
2. nested functions with inout captures cannot be used as arguments not marked
@noescape.
3. nested function with inout captures cannot be a return value.
This change eliminates the need for the shadowing mechanism created for inouts.
foo().getCFString() as String
This cast creates an implicit call expression where the function for the
call is an implicit declref. Instead of choosing "getCFString" as the
location of the declref, we should choose "foo", since otherwise the
overall source range for the call and the coercion will be missing
foo().
Unfortunately there is no good way to test source ranges right now, but
this fixes e.g. the range in the following diagnostic:
struct S {
func getCFString() -> CFString { fatalError("") }
}
_ = S().getCFString() as String + 1
~~~~~~~~~~~~~~~~~~~~~~~ ^ ~ // before
~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~ // now
rdar://problem/26301228
Implement the Objective-C #keyPath expression, which maps a sequence
of @objc property accesses to a key-path suitable for use with
Cocoa[Touch]. The implementation handles @objc properties of types
that are either @objc or can be bridged to Objective-C, including the
collections that work with key-value coding (Array/NSArray,
Dictionary/NSDictionary, Set/NSSet).
Still to come: code completion support and Fix-Its to migrate string
literal keypaths to #keyPath.
Implements the bulk of SR-1237 / rdar://problem/25710611.
semantically unambiguous.
We didn't actually intend to change how programmers normally
constructed these types, but the change to the object literal
syntax accidentally caused these initializers to have very
natural-seeming signatures. These initializers also created
possible ambiguities with the actual initializers. Renaming
them to refer to their function as literal initializers is the
right thing to do.
Unfortunately, this provided to be somewhat annoying, as the
code was written to assume that the argument tuple following
e.g. #colorLiteral could be directly passed to the initializer.
We solve this by hacking on both ends of the constraint system:
during generation we form a conversion constraint to the
original, idealized parameter type, and during application we
rewrite the argument tuple type to use the actual labels.
This nicely limits the additional complexity to just the
parts dealing with object literals.
Note that we can't just implicitly rewrite the tuple expression
because that would break invariants tying the labels to physical
source ranges. We also don't want to just change the literal
syntax again and break compatibility with existing uses.
rdar://26148507
Implements the core functionality of SE-0064 / SR-1239, which
introduces support for accessing the Objective-C selectors of the
getter and setter of an @objc property via #selector(getter:
propertyName) and #selector(setter: propertyName).
Introduce a bunch of QoI around mistakes using #selector to refer to a
property without the "getter:" or "setter:", using Fix-Its to help the
user get it right. There is more to do in this area, still, but we
have an end-to-end feature working.
Much of the implementation and nearly all of the test cases are from
Alex Hoppen (@ahoppen). I've done a bit of refactoring, simplified the
AST representation, and replaced Alex's custom
expression-to-declaration logic with an extension to the constraint
solver. The last bit might be short-lived, based on swift-evolution
PR280, which narrows the syntax of #selector considerably.
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.
