doesn't conform to the associatedtype's protocol (only in diagnostic mode).
This allows the solver to find solutions for more cases involving requirement
failures for dependent member types without special cases across the solver
that check for dependent member types with no type variables.
Just like in cases where both sides are dependent member types
with resolved base that can't be simplified to a concrete type
let's ignore this mismatch and mark affected type variable as a hole
because something else has to be fixed already for this to happen.
If it's possible to build an Objective-C key path for key path
expression make sure that its implicitly generated string literal
expression has a `String` type.
Resolves: rdar://problem/57356196
When an overriding property containing willSet or didSet is not within
a type, the type checker could crash due to a missing "self"
declaration. Check this condition. Fixes rdar://problem/57040259.
The lookupDirect means that we can see type declarations nested inside of a protocol. If we do not filter these invalid declarations, we will offer a bogus fixit on top of a cycle diagnostic. Remove these types from consideration entirely so we don't crash and don't offer bogus fixits.
Resolves rdar://57003317
This commit changes how we represent caller-side
default arguments within the AST. Instead of
directly inserting them into the call-site, use
a DefaultArgumentExpr to refer to them indirectly.
The main goal of this change is to make it such
that the expression type-checker no longer cares
about the difference between caller-side and
callee-side default arguments. In particular, it
no longer cares about whether a caller-side
default argument is well-formed when type-checking
an apply. This is important because any
conversions introduced by the default argument
shouldn't affect the score of the resulting
solution.
Instead, caller-side defaults are now lazily
type-checked when we want to emit them in SILGen.
This is done through introducing a request, and
adjusting the logic in SILGen to be more lenient
with ErrorExprs. Caller-side defaults in primary
files are still also currently checked as a part
of the declaration by `checkDefaultArguments`.
Resolves SR-11085.
Resolves rdar://problem/56144412.
If a protocol requirement has a type that's a nested member
type of another member type, eg,
protocol P {
associatedtype A : Q
func f(_: A.B)
}
Then we don't actually want to use 'f()' to infer the witness
for 'A'. By avoiding doing so, we eliminate some cycles which
can allow some programs to type check that didn't before.
If a property has multiple property wrappers attached, we'll have multiple nested calls, where each call's argument is a call to construct the next wrapper in the chain. However, when we use multiple wrappers consecutively, we cannot just rely on the call's type matching the innermost wrapper's type, because it will match the first wrapper in the sequence of consective wrappers and we'll end up crashing in SILGen. So, we should check if the call's argument is another call and look into that before checking the types.
all cases of missing generic parameters.
In `ComponentStep::take` when there are no bindings or disjunctions, use hole
propagation to default remaining free type variables that aren't for generic
parameters and continue solving. Rather than using a defaultable constraint for
holes, assign a fixed type directly when we have no bindings to try.
This is because we already emit a diagostic to tell the user that the property's type does not match the wrappedValue type, so this diagnostic can be a bit confusing especially because the initializer is synthesized
Push through an easy refactoring to the way we validate and install
implicit constructors. This patch would be NFC but for a regression
test that now must diagnose. #26159 changed validation order in such
a way that the code in validation-test-macosx-x86_64/compiler_crashers_2_fixed/0124-sr5825.swift
used to be accepted. This patch once again changes validation order, so
we now reject this code, restoring the behavior seen on all prior
versions of Swift.
On its face, this test should work. In order for it to do so, witness
matching has to be smarter about the declarations it asks for their
interface type, or it will risk these circular constructions
accidentally being accepted or rejected on a whim.
The GSB will try to form and note invalid constraints, but there are
a few paths that aren't prepared for error types to pop up. Add
a defensive check to formProtocolRelativeType to make sure we don't wind
up force-casting an error type.
Fixes rdar://56116278
The autoclosures generated for the keypath-as-function feature were not added to the list of closures that needed captures computed. In top-level code, this caused a crash. Fixes rdar://problem/56055600.
Number the parameters starting at 1 in order to
match other diagnostics such as
diag::missing_argument_positional, and change the
text to make it explicit that we're referring to
the parameter position (rather than argument
position).
Some old circularity-breaking code caused an unexpected null type, which led to crashes in the decl checker when trying to check that an `appendInterpolation` method in a different file would satisfy the informal requirement for one in a StringInterpolationProtocol conformer. This code appears to now be unnecessary, so this commit removes it. Fixes rdar://problem/55864759.
Remove the parent signature from consideration when computing the
generic signature for an extension. This cuts off a series of crashers
that involved nested extensions with trailing where clauses a la
extension Foo {
extension Foo where Self.Undefined == Bar {
}
}
The inner (invalid) extension technically has a parent signature from
Foo itself. Adding that signature to the GSB means when we go to
register the inner extension's generic parameters we crash.
Since extensions have to occur at the top level, just remove the parent
signature from consideration.
Fixes rdar://55502661
