Recently TupleTypeElt was changed to add an inout bit. It is no
longer valid to construct tuple types whose elements have InOutType,
and instead the flag on the element must be set instead.
Update diagnoseImplicitSelfErrors() for the new convention.
Fixes the only remaining crash in the test case from <rdar://19569255>,
but the original issue were fixed long ago.
I don't have reduced test cases. The original test cases
were a series of frontend invocations in -parse-stdlib
mode.
While the original bugs seem to have been fixed, while
verifying I found a few places where we weren't checking
for null decls property in the ASTContext.
Probably not too useful to check this in, but I don't see it
causing any harm, either.
While trying to diagnose problems with ternary/if statements don't
allow clauses, when type-checked separately, to have unresolved type
variables because that doesn't help to find errors.
Currently `visitAssignExpr` always attempts to use type
derived from destination as a contextual type for assignment
source type-checking, which doesn't always lead to better
results.
Resolves: SR-5081
Fixes a problem related to presence of InOutType in function parameters
which diagnostics related to generic parameter requirements didn't handle
correctly, and improves diagnostics for unsatisfied generic requirements
in operator applications, which we didn't attempt to diagnose at all.
Resolves: rdar://problem/33477726
Also, begin to pass around base types instead of raw InOutType types. Ideally, only Sema needs to deal with them, but this means that a bunch of callers need to unwrap any inouts that might still be lying around before forming these types.
Multiple parts of the compiler were slicing, dicing, or just dropping these flags. Because I intend to use them for the new function type representation, I need them to be preserved all across the compiler. As a first pass, this stubs in what will eventually be structural rules as asserts and tracks down all callers of consequence to conform to the new invariants.
This is temporary.
Part of the fix-it for conversion from optional to raw representable
was inserted at the incorrect position which produces invalid expression.
Resolves: rdar://problem/32431736
The distinction was made between these two because of rdar://25341015,
wherein we needed a diagnostic that could detect the shadowing of
global functions by calls in protocols that don't match any
of the protocol's members.
This used to function by hoping that we had an argument tuple type lying
around after type checking. The expr cleaner would re-write that
type into the AST and we would look up based on it. Now that we write
Type() into the AST on failure, we must instead type check the
component parts of the argument themselves to form a tuple
type to make the lookup.
Doing this allows us to return ErrorType in some circumstances where we
want to communicate that we don't have a usable type rather than writing
ErrorType directly into the type of the expression root, avoiding a
mutation of the expression tree in a failure case.
There are two "RAII cleaners" here:
- CleanupIllFormedExpressionRAII cleans up the Expr in its final state
- ExprCleanser walks the Expr before it is mutated and collects
sub-expressions, then cleans those up after
The subtle difference comes into play if we started to apply the
solution (which can fail, leaving the AST in an inconsistent state)
or if preCheckExpression() modified the AST.
The latter case was causing an ASan failure because we were not
cleaning up type variables in new nodes introduced by
preCheckExpression().
Fix this by moving the preCheckExpression() call out of
solveForExpression(), so that if solveForExpression() is called
with TypeCheckExprFlags::SkipApplyingSolution, we don't mutate the
AST at all.
Sigh...
Fixes <rdar://problem/33277279>.
Special DeclNames represent names that do not have an identifier in the
surface language. This implies serializing the information about whether
a name is special together with its identifier (if it is not special)
in both the module file and the swift lookup table.
When we track which expressions we're already in the middle of type
checking, we need to ensure that we also track the constraint system
which has the types for that expression, and then transfer those types
into our current constraint system so that we do not fail to look them up.
While trying to diagnose problems related to keypath components
don't assume that type of the component is always correct, check
before trying to see if it's bridged type or has members.
Resolves: rdar://problem/33135487
Change the fix-it to move the argument to its correct location in one go. This happens by removing it from one location and inserting it in the other (as opposed to the original implementation which swapped one argument with the preceding one). The commas separating the arguments are adjusted to match the moved argument.
Add new tests for reordering regular arguments, variadic arguments, and function arguments.
Resolves: SR-4715 rdar://problem/31849281
Fixes crasher in diagnostics related to the fact that contextual type
is not always available when trying to diagnose problems related to
calls with trailing closures.
Resolves: rdar://problem/33067102
Relax restriction placed on the function shadowing diagnostics
and allow such diagnostics to be emitted even when argument types
do not match expected parameter types, but use "near match" message
in that case to clarify that shadowing is not exact.
Resolves: rdar://problem/32854314
When trying to diagnose problems related to calls where
function is represented by a member of nominal type let's
attempt to be more cautious while type-checking function
expression without it's arguments, because it could produce
unrelated diagnostics.
Resolves: rdar://problem/32551313, rdar://problem/28456467, rdar://problem/31671195
Currently some contextual errors are discovered too late
which leads to diagnostics of unrelated problems like argument
mismatches, these changes attempt to improve the situation
and try to diagnose contextual errors related to calls
before everything else.
Resolves: SR-5045, rdar://problem/32934129
