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
Also remove the decl from the known decls and remove a
bunch of code referencing that decl as well as a bunch of other
random things including deserialization support.
This includes removing some specialized diagnostics code that
matched the identifier ImplicitlyUnwrappedOptional, and tweaking
diagnostics for various modes and various issues.
Fixes most of rdar://problem/37121121, among other things.
This partially reverts commit 8685ee01a1.
The tests are still in place, but the code change is no longer necessary
now that IUOs are removed from the type system.
Fixes: rdar://problem/37013789
Allow passing Optional<T> as inout where
ImplicitlyUnwrappedOptional<T> is expected, and vice-versa.
Swift 4.1 added a warning that overloading inouts by kind of optional
was deprecated and would be removed, but we didn't actually allow
people to remove an overload and pass arguments of the other kind of
optional to the remaining function.
Fixes rdar://problem/36913150
Class constraints (spelled T: AnyObject) on generic types were not
getting checked on generic arguments. This appears to be a regression
introduced in Swift 4.0 with the removal of AnyObject, leading to a
fairly significant soundness hole that could produce crashers later
on.
Fixes SR-6841 / rdar://problem/36884025.
When binding an optional value, or function that returns an optional
value, if that value was produced from a decl that was declared an
IUO, create a disjunction.
After solving, make use of the disjunction choices in rewriting
expressions to force optionals where needed.
This is disabled for now, as it results in a source compatibility
issue without associated changes that actually start generating
Optional<T> in place of ImplicitlyUnwrappedOptional<T>. It's
complicated, but basically having two '??' (one returning T, one
returning T?) and creating a disjunction where the first (favored)
choice is ImplicitlyUnwrappedOptional<T> and second is T results in
our selecting the wrong '??' in some cases.
Use this in places where we have a decl that is marked with the
ImplicitlyUnwrappedOptionalAttr so that we can distinguish in the
solver which decls need to be potentially unwrapped in order to type
check successfully.
