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)
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
We've had a load-bearing optimization that avoids rebuilding
the generic signature of the protocol extension to avoid a
cycle involving a typealias in the extension that's mentioned
as a requirement in the protocol, for example:
```
public protocol P3 {
associatedtype A
}
public protocol P4: P3 where A == B {}
extension P4 {
public typealias B = String
}
```
What was happening is that we're inside a
StructuralRequirementsRequest, so we're performing TypeResolution
in the Structural stage. When we encounter this typealias that's
within a protocol extension, we'd end up accidentally requesting
the interface type of that alias through
`TypeChecker::substMemberTypeWithBase`
(via `aliasDecl->getUnderlyingType()`).
What we should do instead is call `aliasDecl->getStructuralType()`
and skip the substitution during that stage.
There happened to already be code doing this, but it was only
kicking in if the DeclContext `isa<ProtocolDecl>`, which excludes
extensions of a protocol. I see no reason why extensions of a
protocol should be excluded, so I assume it was unintentional.
Thus, the fix boils down to using `DeclContext::getSelfProtocolDecl`
which does include extensions of protocols. With this fix, the
optimization is no longer load-bearing on the example above.
See the history of this hack in f747121080
or rdar://problem/129540617
Make sure we preserve the result expression for an out-of-place
`return`, or a non-`nil` result in an initializer. This ensures we
can still provide semantic functionality from them and fixes a crash
where we would fail to type-check a binding.
We know this is where the issue is so we can immediately bind to a hole,
ensuring we don't produce unnecessary downstream diagnostics from
things we can't infer.
When a DeclRefTypeRepr is bound to a known declaration, the exact DeclNameRef used to create it is erased. This means that we no longer know exactly which module selector was used in the source code, so repeating the lookup with the same instance might produce different results.
Avoid this problem by reusing the bound decl instead of trying to look up the same declaration again.
Fixes rdar://164647850.
Make sure we query the constraint system for a type if we have a local
property wrapper in a closure to avoid kicking interface type
computation outside the closure, and make sure we map into context if
we need to.
Support pack expansion types in term rewriting, maintaining shape invariants and not
throwing assertions unnecessarily.
Additional tests added for an inifinite case and a concrete case.
We already reject attempts to reference this for `lazy` properties.
For `lazy` locals let's just not expose it to name lookup to begin
with. This ensures we don't attempt to prematurely kick the interface
type computation for the var, fixing a couple of crashers.
This test case crashes when prepared overloads are disabled, but passes
when enabled. To avoid messing up tests if we have to turn the flag on
and off, fix the crash.
Prints a regular error instead of crashing.
The check is done in SILGen, because it's simple. We could also do it earlier, but I don't see a strong reason for this.
rdar://75950093
When a method is called with fewer than two parameter lists,
transform it into a fully-applied call by wrapping it in a
closure.
Eg,
Foo.bar => { self in { args... self.bar(args...) } }
foo.bar => { self in { args... self.bar(args...) } }(self)
super.bar => { args... in super.bar(args...) }
With this change, SILGen only ever sees fully-applied calls,
which will allow ripping out some code.
This new way of doing curry thunks fixes a long-standing bug
where unbound references to protocol methods did not work.
This is because such a reference must open the existential
*inside* the closure, after 'self' has been applied, whereas
the old SILGen implementation of curry thunks really wanted
the type of the method reference to match the opened type of
the method.
A follow-up cleanup will remove the SILGen curry thunk
implementation.
Fixes rdar://21289579 and https://bugs.swift.org/browse/SR-75.
Fixes crashes in 28437-swift-typechecker-validatedecl.swift (from previous commit)
and the compiler crasher 28861-gpdecl-getdepth-generictypeparamdecl-
invaliddepth-parameter-hasnt-been-validated.swift.
