This helps to postpone attempting bindings related to generic
parameters with all else being equal.
Consider situation when function has class requirement on its
generic parameter. Without such requirement solver would infer
sub-class for `T`. But currently when requirement is present base
class is inferred instead, because when bindings for such generic
parameter are attempted early single available binding at that
point comes from the requirement.
```swift
class BaseClass {}
class SubClass: BaseClass {}
struct Box<T> { init(_: T.Type) {} }
func test<T: BaseClass>(box: Box<T>) -> T.Type {
return T.self
}
test(box: .init(SubClass.self)) // `T` expected to be `SubClass`
```
Resolves: [SR-9626](https://bugs.swift.org/browse/SR-9626)
Resolves: rdar://problem/47324309
After collecting possible conformances and types for each argument,
`ArgumentInfoCollector` attempts literal protocol minimalization
to reduce the set of possible types argument could assume. Let's
exclude literal protocols without default types like
`ExpressibleByNilLiteral` from consideration by that algorithm.
Resolves: rdar://problem/47266563
This is a follow-up to https://github.com/apple/swift/pull/21783
which made `is{Setter}AccessibleFrom` respect `-disable-access-control`
flag. Now it's `getAdjustedFormalAccess` turn to do the same.
Solving Bind is a little easier than Equal. The only remaining uses of Equal
are in the .member syntax and keypaths; if we can refactor those, we might be
able to simplify LValue handling in the type checker in general.
- Avoid creating an unnecessary type variable
- Even if both sides are type variables we can solve them if the LHS cannot
bind to an InOut or the RHS cannot bind to an LValue; in this case the two
types are identical and we can merge them
Try to fix constraint system in a way where member
reference is going to be defined in terms of its use,
which makes it seem like parameters match arguments
exactly. Such helps to produce solutions and diagnose
failures related to missing members precisely.
These changes would be further extended to diagnose use
of unavailable members and other structural member failures.
Resolves: rdar://problem/34583132
Resolves: rdar://problem/36989788
Resolved: rdar://problem/39586166
Resolves: rdar://problem/40537782
Resolves: rdar://problem/46211109
If lookup couldn't find anything matching given name, let's try to
fake its presence based on how member is being used. This is going
to help (potentially) type-check whole expression and diagnose the
problem precisely.
We're looking at the generic signature of the extension, so it must
have been validated at this point.
I don't have a test case for this and maybe it never came up, but
nothing forces it to be validated here so let's make it more robust
by doing it explicitly.
Two problems here:
- The InterpolatedString instance variable was not always initialized before
being checked for null
- In the non-null case, we were assuming the result of CallExpr::getCalledValue()
was non-null, but it's null if the callee is not a function declaration
Fixes <rdar://problem/46973064>.
The logic here had diverged from UnqualifiedLookup. One day we'll merge
the two, for now clean it up a bit to match.
Note that all generic parameters now have 'Reason' reported as 'Local'.
I don't believe this really matters.
Fixes <rdar://problem/20530021>.
Consider this setup:
protocol Proto {
func foo() {}
}
class Base : Proto {
func foo() {}
}
class Derived : Base {
...
}
When completing members of a Derived instance, we find both the protocol's
foo() and the base class's foo(). These have the following types:
- Proto.foo: <Self : Proto> (Self) -> () -> ()
- Base.foo: (Base) -> () -> ()
If we simply substitute the base type (Derived) into the type of the protocol
member, we get (Derived) -> () -> (), which is different than the type of
Base.foo, so we get both declarations in the completion list.
Instead, use the 'Self' type for the specific class of the conformance,
which in this case is 'Base' even if we're looking at members of 'Derived'.
Fixes <rdar://problem/21161476>, <https://bugs.swift.org/browse/SR-1181>.
Since the rule is to prioritize names over types, let's diagnose
ambiguous solutions containing subscript operator fix as missing
member and list possible candidates to use.
Fix to use subscript operator instead of spelled out name helps
to produce a solution, that makes it much easier to diagnose
problems precisely and provide proper fix-its, it also helps to
diagnose ambiguous cases, and stacks up nicely with other errors.
This is a new feature of Swift 5 mode, so it deserves at least a
little bit of explanation right in the diagnostic. If you have an
otherwise-fully-covered switch but can't assume the enum is frozen,
you'll now get this message:
switch covers known cases, but 'MusicGenre' may have additional
unknown values
Furthermore, if the enum comes from a system header, it looks like
this:
switch covers known cases, but 'NSMusicGenre' may have additional
unknown values, possibly added in future versions
...to further suggest the idea that even though your switch is covered
/now/, it might not handle everything in the /future/. This extra bit
is limited to system headers to avoid showing up on C enums defined in
your own project, for which it sounds silly. (The main message is
still valid though, since you can cram whatever you want into a C
enum, and people use this pattern to implement "private cases".)
rdar://problem/39367045
