Introduce a new fix kind into the constraint solver to cover unwrapping the base
of a member access so we can refer to the a member of the unwrapped base.
Wire this fix kind to the just-added diagnostic that suggests either the
chaining ‘?’ or the force-unwrap ‘!’ via separate, descriptive Fix-Its.
Example:
error: value of optional type 'X?' must be unwrapped to refer to member 'f' of wrapped base type 'X'
let _: Int = x.f()
^
note: chain the optional using '?' to access member 'f' only for non-'nil' base values
let _: Int = x.f()
^
?
note: force-unwrap using '!' to abort execution if the optional value contains 'nil'
let _: Int = x.f()
^
!
Before this, we would sometimes get a Fix-It for just ‘?’ and sometimes get a Fix-It for the
coalescing ‘??’, neither of which is likely to be right.
More work on rdar://problem/42081852.
More groundwork for protocols with superclass constraints.
In several places we need to distinguish between existential
types that have a superclass term (MyClass & Proto) and
existential types containing a protocol with a superclass
constraint.
This is similar to how I can write 'AnyObject & Proto', or
write 'Proto1 & Proto2' where Proto1 has an ': AnyObject'
in its inheritance clause.
Note that some of the usages will be revisited later as
I do more refactoring and testing. This is just a first pass.
In Swift 4, constructors had the same name as properties,
methods and enum cases named `init`. This meant that you
could use constructor syntax to call such a member, which
caused some confusing behavior.
Recently I added a special declname for `init` so that
constructors have unique names distinct from any name you
can spell, and "foo.init" syntax would look for a member
with the special name rather than one named `init`.
Unfortunately people actually had code where they defined
members named `init` and then use them via normal member
lookup syntax, like this:
enum E {
case `init`
}
let e: E = E.init
So to maintain backward compatibility, hack member lookup
to also find members named `init` when looking up the special
declname for constructors.
The workaround is only enabled in Swift 4 and 4.2 mode;
in Swift 5 mode you are expected to write "foo.`init`" to access
non-constructor members named `init`.
Fixes <rdar://problem/38682258>.
Refactor the interface to return a bit vector. Along the way, fix up
the callers and remove some dead usages of the defaults information
that were copied and pasted around Sema.
Since member lookup doesn't check requirements
it might sometimes return types which are not
visible in the current context e.g. typealias
defined in constrained extension, substitution
of which might produce error type for base, so
assignement should thead lightly and just fail
if it encounters such types.
Resolves: rdar://problem/39931339
Resolves: SR-5013
Only two more of these exist
1) CSGen's formation of @lvalue -> inout conversion constraints
2) WritableKeyPath's checking rules
Both can be eliminated but will require more refactoring.
8271c1a removed the last hacky usage of ArrayElementType,
leaving behind just the @lvalue-to-inout conversions. Rename
the locator path element to reflect this and do a bit of cleanup on the
unrelated-but-near-enough other hack RValueAdjustment.
Disallow implicit conversion or arguments from Array, String, and
InOut (formed by &) to pointer types if the argument is for an
@autoclosure parameter.
These conversions were really only intended to be used for C/ObjC
interop, and in some contexts like autoclosures they are not safe.
Fixes: rdar://problem/31538995
We inadvertantly allowed this in the past, so continue to do so when
compiling in Swift 3/4 mode to avoid suddenly breaking existing code.
The diagnostic here is pretty bad, and I've opened issues for that as
well as providing some kind of deprecation warning for this so that
even under Swift 3/4 mode we alert users that this is unsupported.
rdar://problem/39802797
Given something like `max(1, 2)` inside a type that conforms to Sequence, this
allows the compiler to consider Swift.max as well as the two methods with that
name on Sequence.
`AbstractStorageDecl::isSettable` by itself doesn't account for access control, so we need to check `isSetterAccessibleFrom` as well. Furthermore, key paths should not get the special context-sensitive privileges direct accesses do, such as initializers being able to assign into `let` properties. Fix the type checking logic here to only create a statically writable KeyPath value when the referenced declaration has a setter visible independent of current context. Fixes SR-6667 | rdar://problem/36257266.
That hack resulted in already matching argument and parameter to end
up not matching in this case.
Fixes https://bugs.swift.org/browse/SR-7191
and rdar://problem/38798063
Many (perhaps most?) calls to createTypeVariable explicitly pass 0 for
options. This change just defaults the parameter to 0 and removes all
the explicit 0's in the code.
This likely affects other things too, but literals are where it appears
most. Previously, the mid-solving literal types like Array<$T0> were
just checked for whether they conformed to the protocol, without
acknowledging that this might introduce requirements on $T0, instead the
conditional requirements were checked against $T0, and so
failed (there's no reason that $T0 should satisfy the requirements at
all, it's a recently-constructed transient type variable). Instead,
capture the requirements and add them as constraints to the type
variable.
Fixes https://bugs.swift.org/browse/SR-7192 and rdar://problem/38461036
and improves https://bugs.swift.org/browse/SR-6941.
Allow certain bindings and conversions involving non-escaping
function types to succeed in "diagnostic" mode to gather fixes
and diagnose such problems better, expecially related to
conversions to 'Any' and generic parameters.
Resolves: rdar://problem/38648760
Currently we always use 'FunctionResult' as a path element when matching
function result types, but closure result type is allowed to be implicitly
converted to Void, which means we need to be careful when to use
'FunctionResult' and 'ClosureResult'.
Resolves: rdar://problem/37790062
* Implement the recently accepted SE-0195 proposal, which introduces "Dynamic
Member Lookup" Types. This is a dusted off and updated version of PR13361,
which switches from DynamicMemberLookupProtocol to @dynamicMemberLookup as
was requested by the final review decision. This also rebases it,
updates it for other changes in the compiler, fixes a bunch of bugs, and adds support for keypaths.
Thank you to @rudx and @DougGregor in particular for the helpful review comments and test cases!
Allow functions with type `(()) -> T` to be passed in places where we
expect `() -> T`, but only for -swift-version 4 (for -swift-version 3
this already works due to other horrible things in CSSimplify.cpp).
We need to look at how we can help migrate these cases to
-swift-version 5, but in the meantime, but that is something we can
consider separately.
We inadvertantly allowed a function conversion for Swift 4 that we did
not intend to allow.
This commit adds an extremely narrow fix to continue to allow this for
-swift-verson 4 only.
Fixes rdar://problem/36875195 / https://bugs.swift.org/browse/SR-6837
Increase solution score when performing function conversions where only
one side has `@autoclosure`. That is going to help pick the best overload
when only difference lays in presence of such attribute.
e.g.
```swift
func foo(_: @autoclosure () -> Int) {}
func foo(_: () -> Int) {}
```
If the argument is itself `@autoclosure` it's preferable to use overload
with `@autoclosure` attribute, otherwise `() -> Int` should be used.
Resolves: rdar://problem/37160679
