In #65125 (and beyond) `matchTypes`, has logic to attempt to wrap an
incoming parameter in a tuple under certain conditions that might help
with type expansion.
In the case the incoming type was backed by a `var`, it would be wrapped
by an `LValueType` then be subsequently mis-diagnosed as not-a-tuple.
More details in #85924 , this this is also the cause of (and fix for)
#85837 as well...
Impact for an unknown property access was frequently higher than other options
on ambiguous selections, by 3 to 5 points, causing fix selections that were
farther away and frequently noted to be in accurate. This commit lowers the
impact to be in a similar range to other fixes and this causes property accesses
to be selected more proprotionaly.
In the existing test suite, this changed the diagnostic only in the case of
protocol composition, which was also discovered to be a flawed binding lookup.
Tests added for the property lookup, tests updated for protocol composition
(Including correcting a likely error in a test specification)
We noticed that a project failed to build with prepared overloads enabled,
but built successfully with prepared overloads disabled.
It turns out that the code clearly should never have been accepted in the
first place, because the type checker was making an arbitrary choice between
two nominal type declarations with the same name.
Further inspection revealed this was because of a FIXME added in 2013 which
was far too broad. Tighten up the logic here to only disambiguate if at least
one of the two declarations is a type alias, and it has the same underlying
type as the other one. A choice between unrelated nominal type declarations
should always be ambiguous.
This still isn't perfect, because we might have two generic type aliases
that are referenced in both solutions with different substitution maps,
in which case we will still erroneously pick the first one. But this
is better than the old logic, at least.
Fixes rdar://165863775.
If arguments are represented by a single tuple it's possible
that the issue is not about missing parameters but instead
about tuple destructuring. Fix `fixMissingArguments` to check for
overruns after destructuring and stop if that produces more
arguments then parameters because such situations are better
diagnosed as a general conversion failure rather than a missing
argument(s) problem.
Resolves: rdar://159408715
This fixes an ambiguity introduced by the stdlib change in
0f99458900.
Since (borrowing T) -> () and (T) -> () both convert to
each other, we could end up with ambiguous solutions where
neither one was better than the other. Generalize the
existing trick we use for labeled vs unlabeled tuples to
also strip off ownership specifiers and @convention(...)
from function types. This fixes the regression, as well
an existing FIXME in a test I added a while ago where
the same problem arises with @convention(block).
This reverts commit 6852bc9834.
In addition to the original change, this makes sure that C++ `std::string` and Swift `String` are given distinct score, in order to prevent ambiguity which was causing build failures in some projects.
rdar://158439395
Exclude properties with initial values from the memberwise initializer
if they are less accessible than the most accessible property, up to
`internal`. Introduce a compatibility overload that continues to
include the same properties as before until the next language mode.
This is gated behind the `ExcludePrivateFromMemberwiseInit` feature.
rdar://122416579
Currently `init` accessors are always memberwise initialized, but I'm
planning on changing that. As such we need to make sure we record
the `init` accessor regardless of whether it is included in the memberwise
init.
This serves as the backing request for both InitAccessorPropertiesRequest
and MemberwiseInitPropertiesRequest, ensuring the former does not
care about the init accessor is included in the memberwise initializer.
Store the original VarDecl in the same map we use for tracking the
original wrapper var for property wrappers. This will allow us to
use the same logic to determine the original var for both.
We already had bookkeeping to track which statement in a multi-statement
closure we were looking at, but this was only used for the 'reasonable time'
diagnostic in the case that we hit the expression timer, which was almost
never hit, and is now off by default. The scope, memory, and trial limits
couldn't use this information, so they would always diagnose the entire
target being type checked.
Move it up from ExpressionTimer to ConstraintSystem, so that we get the
right source location there too. Also, factor out some code duplication
in BuilderTransform to ensure we get the same benefit for result builders
applied to function bodies too.
Add a note to missing explicit `Sendable` conformance warning
(produced by `-Wwarning ExplicitSendable`) and a fix-it with
a suggestion to suppress `Senable` conformance via `~Sendable`.
Handle the following situation:
```swift
struct S {
func test() {}
static func test(_: S) {}
}
```
Calling `S.test(s)` where `s` has a type `S` without any other context
should prefer a complete call to a static member over a partial
application of an instance once based on the choice of the base type.
The behavior is consistent for double-applies as well i.e.
`S.test(s)()` if static method produced a function type it would be
preferred.
Resolves: rdar://165862285
As with all other where clauses, we must resolve the requirements twice;
first in structural stage to build the generic signature, and second in
interface stage to check that any generic types that appear within
satisfy requirements. We weren't doing the latter for @specialize, which
would result in SIL crashes if such invalid SIL types appeared therein.
Fixes rdar://165909327.
