If there is a single candidate with a valid index type, don't assume
that such candidate always has a valid function type. There are
multiple examples of this crash we've seen but there is no reproducer
test-case unfortunately.
Resolves: rdar://problem/37565861
* Implement the recently accepted SE-0195 proposal, which introduces "Dynamic
Member Lookup" Types. This is a dusted off and updated version of PR13361,
which switches from DynamicMemberLookupProtocol to @dynamicMemberLookup as
was requested by the final review decision. This also rebases it,
updates it for other changes in the compiler, fixes a bunch of bugs, and adds support for keypaths.
Thank you to @rudx and @DougGregor in particular for the helpful review comments and test cases!
This is useful for explicit casts and type expressions, where
type loc and expression types might be different, and allows
constraint solver to avoid setting opened types to expressions
which resolves multiple crashes.
When binding an optional value, or function that returns an optional
value, if that value was produced from a decl that was declared an
IUO, create a disjunction.
After solving, make use of the disjunction choices in rewriting
expressions to force optionals where needed.
This is disabled for now, as it results in a source compatibility
issue without associated changes that actually start generating
Optional<T> in place of ImplicitlyUnwrappedOptional<T>. It's
complicated, but basically having two '??' (one returning T, one
returning T?) and creating a disjunction where the first (favored)
choice is ImplicitlyUnwrappedOptional<T> and second is T results in
our selecting the wrong '??' in some cases.
Use this in places where we have a decl that is marked with the
ImplicitlyUnwrappedOptionalAttr so that we can distinguish in the
solver which decls need to be potentially unwrapped in order to type
check successfully.
Add a new OverloadChoiceKind for decls that are either IUO-typed, or
function-typed meaning that the function result type is IUO-typed.
Not currently used, so NFC.
Also remove mention of the word “contextual” type from the diagnostic
that rewrites array literals into dictionary literals and scale back
the scope of the diagnostic. This method was catching and
mis-diagnosing too many errors that could better be handled by invalid
conversion diagnostics.
While trying to diagnose a problem related to contextual result type
of the trailing closure, don't assume that declaration context is properly
set, instead directly set it to correct one before running type-check.
Resolves: rdar://problem/35699666
We now store an entire OverloadChoice in the unviable candidates
list (which is used for error recovery), just like we store them
for viable candidates.
The additional information isn't used, so NFC.
conformsToProtocol() is the main way in which we check whether a given type
conforms to a given protocol. Extend it to check conditional requirements by
default, so that an unmodified caller will get the "does not conform" result
(with diagnostics when a location is present) rather than simply ignoring
the conditional requirements.
Some callers take responsibility for conditional requirements, e.g., to
push them into the constraint system. Allow those callers to opt out of
this checking, and do so wherever appropriate.
Fixes rdar://problem/35518088, where we were ignoring the conditional
requirements needed to verify that Equatable synthesis could be performed.
This includes functions without type parameters that are generic
because they are members of a generic context. This addresses a
diagnostics regression because the '==' operators for Optional, Array,
and Dictionary were made into members.
The resulting error message is a little ugly, but is more informative
(and much shorter) than what we had before.
Consider different overload choices for the same location in evaluation
order, this makes overload resolution more predictable because it's going
to follow expression bottom-up, that prevents situations when some
expressions are considered ambigious because choices taken further up
equate the score, instead each level is given distinct weight
based on evaluation order.
Resolves: rdar://problem/31888810
This includes functions without type parameters that are generic
because they are members of a generic context. This addresses a
diagnostics regression because the '==' operators for Optional, Array,
and Dictionary were made into members.
The resulting error message is a little ugly, but is more informative
(and much shorter) than what we had before.
subscript is on the destination side of an assignment and restricting matching
overload candidates to only the set-able members.
Also, if we are left with a single candidate, we can recheck unresolved index
expressions with better parameter info.
CSDiag was misinterpreting the result of checkGenericArguments().
A result of SubstitutionFailure does not mean a diagnostic was
emitted, only a result of Failure means that. This fixes a case
where we did not emit a diagnostic, result in a crash on invalid.
The diagnostic is still poor, but that's better than crashing.
Fixes <https://bugs.swift.org/browse/SR-5932>,
<rdar://problem/34522739>.
We are currently in process of removing `InOutType`
so `VarDecl::get{Interface}Type` is going to wrap base
type into `InOutType` if its flag indicates that it's
an `inout` parameter declaration. But such type can't
be restored directly using `VarDecl::set{Interface}Type`
caller needs additional logic to extract base type.
Resolves: rdar://problem/33613329
The base mutability of storage is part of the signature, so be sure
to compute that during validation. Also, serialize it as part of
the storage declaration, and fix some places that synthesize
declarations to set it correctly.