Rather than mutating the parameter pattern in place and separately
return whether an error occurred, return the new pattern or NULL if an
error occurred. While here, switch over to ContextualPattern for the
input.
And get rid of that infernal "goto".
The diagnostic is still terrible, but at least we shouldn't crash.
Fixes one manifestation of <rdar://problem/57726880>.
I also filed <https://bugs.swift.org/browse/SR-11989> to track improving
the diagnostic.
Fixes rdar://problem/53678041 and rdar://problem/57676337; the former was
because we diagnosed unavailable wrappedValue at the null source location
originall, then started suppressing that diagnostic altogether. Produce a
proper diagnostic now.
* diagnostic when a closure parameter is declared with type sugar
* Use a test that was already commmited for SR-11724
i
* Use isa<T> instead of asking for the kind directly
* Fix nit: Remove a whitespace
The semantic checks for CodingKeys are being duplicated across the value witness synthesis code paths. Just synthesize a CodingKeys enum and let validateCodingKeysEnum do the heavy lifting when we actually need to go emit diagnostics.
With the new way of caching overloads in the
constraint system, we no longer allow different
overloads to be resolved for the same locator in
the same scope.
Adjust the property wrapper logic
so that it appends Member locator elements for
nested lookups.
Swift classes cannot meaningfully conform to NSObjectProtocol.
Inheriting from NSObject is the appropriate fix, so suggest that.
Fixes rdar://problem/32543753.
Previously, property names are hidden in the whole range of the
declarations. Now, it's only hidden in its own initializer range.
rdar://problem/49697202
It might be either impossible to infer the base because there is
no contextual information e.g. `_ = .foo` or there is something
else wrong in the expression which disconnects member reference
from its context.
If none of the candidates produce expected contextual type, record
all of the posibilities to produce a note per and diagnose this as
contextual type mismatch instead of a reference ambiguity.
The computation for "is explicitly initialized" on a pattern binding
entry didn't account for explicit initialization via the property
wrapper (e.g. @Wrapper(closure: { ... })), which lead to a crash for
properties with optional type. Fixes rdar://problem/57411331.
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.
It was being used purely to get the name of the type context for a diagnostic
message. SourceKit's syntactic-only requests were hitting an assertion when
this diagnostic was triggered because they don't set up a type checker.
This breaks source compatibility a little bit more than we'd like, so
reverting it for now.
Fixes <rdar://problem/57213598>.
This reverts commit 04fbcc0149.
When realizing a type like Foo<A>.Bar, we have to account for the
possibility that Bar is defined in a constrained extension of Foo,
and has generic requirements beyond those that Foo itself places
on 'A'.
Previously we only handled this for types referenced from the
constraint system as part of openUnboundGenericType(), so we were
allowing invalid types through in type context.
Add the right checking to applyGenericArguments() to close the
hole. Note that the old code path still exists in the constraint
solver; it is used for member accesses on metatype bases only.
Fixes <https://bugs.swift.org/browse/SR-10466>.
