Avoid a re-typecheck in `diagnoseContextualConversionError` if the
expression type is already known and only return `true` if we know
that at least one error diagnostic has been emitted otherwise there
is a risk that type-check is going to return without any and fail
in verifier.
Resolves: rdar://problem/40002266
Avoid a re-typecheck in `diagnoseContextualConversionError` if the
expression type is already known and only return `true` if we know
that at least one error diagnostic has been emitted otherwise there
is a risk that type-check is going to return without any and fail
in verifier.
Resolves: rdar://problem/40002266
* [Diagnostics] SR-7445 Improve diagnostics for assignment failures
* modified messages for assignments to function calls,
modified messages for assignments to methods.
removed comment for resolved radar.
* removed extra line and braces
* added tests for assignment_lhs_is_apply_expression
eliminated redundant literal check which is always invoked before call
reverted 'cannot assign to value' for literal assignments in subexpressions
* Complemented assigning to literal tests & reverted to 'cannot asign to value' for methods (was 'cannot assign to member')
* removed extra tabs
* eliminated one more accidental spacing
* Update CSDiag.cpp
* added highlighting, fixed & rechecked tests
* added highlighting for complex expressions involving assigning to literals
Resolves: [SR-7445](https://bugs.swift.org/browse/SR-7445)
When we type check a closure expression with inferred parameter
types, we assign type variables to them. If type checking fails,
we end up in FailureDiagnosis::diagnoseClosureExpr().
If there was no contextual type, we would skip the code path
which nukes type variables in the closure's ParamDecls before
proceeding to type check the body. Type checking of the body
creates a new constraint system which would pick up the outer
constraint system's type variables and blow up.
Fixes <rdar://problem/39489003>.
Declarations with special names (e.g. (de-)init and subscript) don't have
identifiers so while trying to diagnose specific problems related to
members check if they have a kind appropriate to the situation.
Resolves: rdar://problem/39514009
Continue to emit notes for the candidates, but use different text.
Note that we can emit a typo correction fix-it even if there are
multiple candidates with the same name.
Also, disable typo correction in the migrator, since the operation
is quite expensive, the notes are never presented to the user, and
the fix-its can interfere with the migrator's own edits.
Our general guidance is that fix-its should be added on the main
diagnostic only when the fix-it is highly likely to be correct.
The exact threshold is debateable. Typo correction is certainly
capable of making mistakes, but most of its edits are right, and
when it's wrong it's usually obviously wrong. On balance, I think
this is the right thing to do. For what it's worth, it's also
what we do in Clang.
A protocol extension of a private protocol can define internal
or public members. We should not be able to find these members
from another file or module if an internal or public type
conforms to the protocol.
Fixes <rdar://problem/21380336>.
Many (perhaps most?) calls to createTypeVariable explicitly pass 0 for
options. This change just defaults the parameter to 0 and removes all
the explicit 0's in the code.
They can show up when re-typechecking via diag or code-completion and were
only being sanitized out in one place in CSDiag. Moved that logic into
SanitizeExpr.
Resolves rdar://problem/38149042
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.
