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".
* [Sema][Diagnostics] Add fixit for warning when inferring an undesirable type
* [Sema][Diagnostics] Generalize undesirable type warning to include arrays of empty tuples
https://bugs.swift.org/browse/SR-11511
Patch up all the places that are making a syntactic judgement about the
isInvalid() bit in a ValueDecl. They may continue to use that query,
but most guard themselves on whether the interface type has been set.
Use it to provide an idealized API for the VarDecl case in validateDecl.
In reality, a lot of work is needed to rationalize the dependency
structure of this request. To start, the callers of
typeCheckPatternBinding must be eliminated piecemeal. Once that is
done, the AST should introduce pattern binding decls along all the
places where getParentStmt() used to apply.
Define a request that can be used to grab the fully validated and
type-checked form of a given pattern binding entry. Using this,
validation of pattern bindings is fully disconnected from validation of
bound variables, and cycles are now picked up by the request evaluator.
Using this, we can go clean up all the callers that are checking a bit
and calling back into typeCheckPatternBinding. It will also serve as
the basis for a request for the naming pattern for a VarDecl which will
clean that part of validateDecl.
We can use the existing logic for checking recursion in
declaration validation. This eliminates some bogus
diagnostics and allows some weird logic to be removed
from typo correction.
This fixes two easy cases where we would go exponential in type
checking tuple literals.
Instead of generating a conversion to a single type variable (which
results in one large constraint system), we generate a conversion ot
the same type that appears in the initializer expression (which for
tuples is a tuple type, which naturally splits the constraint system).
I experimented with trying to generalize this further, but ran into
problems getting it working, so for now this will have to do.
Fixes rdar://problem/20233198.
Instead of the simple "expected identifier in declaration", the error will now read "keyword '%' cannot be used as an identifier here", and will be accompanied by a note suggesting escaping the keyword with backticks, as well as a fixit.
https://bugs.swift.org/browse/SR-3167
If we found any error in a list, in most cases, we cannot expect that the
following tokens could construct a valid element. Skip them, instead of trying
to parse them as the next element. This significally reduces bogus diagnostics.
Bailout if seeing tok::eof or token that can never start a element, after
parsing an element. This silences superfluous "expected ',' separator" error,
or misleading expected declaration error. What we should emit is
"expected ')' in expression list, or "expected '}' in struct".
- Remove stray newline
- Adjust wording when recommending backticks for a keyword identifier
- Provide fix-it when encountering a keyword as an identifier
rdar://problem/25761380
When declaring a function like func repeat(){}, the diagnostic is
"expected an identifier" but 'repeat' looks like a reasonable
identifier at first glance, so actually say why it isn't.
rdar://problem/25761380
- Improve the specific cases of nil and empty collection literals.
- Improve cases of contextual member lookup where the result type of the looked up member disagrees with context.
- Add some fixme's to the testsuite for cases of this diagnostic that should be diagnosed in other ways.
ASTPrinter of type variables was trying to dig an original type out of the
locator and archetype that opened the type variable in the first place. This
was prone to failure and never helped, so just always print type vars as _.
The affected diagnostics always come out better and this saves a word of storage
for each type variable.
Rearrange diagnoseGeneralConversionFailure to diagnose structural problems
even if we have some UnresolvedTypes floating around, then reject constraint
failures with UnresolvedTypes in them even harder. This keeps us giving
good errors about failures where we have a structural problem (with buried
irrelevant details) while not complaining about cases that are actually
ambiguous.
The end result of this is that we produce a lot better error messages in the
case of failed archetype inference. This also highlights the poor job we do
handling multi-stmt closureexprs...
and diagnoseGeneralConversionFailure(). The previous approach of trying
to dig into anchors would often lead to complaining about types at
different levels in the same diagnostic, and the complexity of the former
code isn't needed now that other changes have landed.
Swift SVN r31036
The exact message is mostly immaterial at this point, but without the
change we end up recursively validating the property, marking it invalid,
and then never actually emitting a diagnostic, leaving SILGen and
Serialization to go ahead and fail.
rdar://problem/20913392
Swift SVN r30830
which we have a contextual type that was the failure reason. These are a bit
longer but also more explicit than the previous diagnostics.
Swift SVN r30669
in case the tuple type has fewer elements.
<rdar://problem/21081340> SourceKit crashed while rapidly undoing: Assertion failed: (Index < Length && "Invalid index!")
Swift SVN r29082
initializer has been type-checked, rather than a bit for the entire
PatternBindingDecl.
<rdar://problem/21057425> Crash while compiling attached test-app.
Swift SVN r29049
var/let bindings to _ when they are never used, and use some values that
are only written. This is a testsuite cleanup, NFC. More to come.
Swift SVN r28406
This pushes tuple pattern labels forward:
- Actually record them in TuplePatternElt.
- Remove the tuple shuffle ban that prevents some cases
(e.g. the one in the radar) of a tuple with labels being shuffled
onto a tuple without labels.
- Remove dead code enabled by removing the restriction.
Swift SVN r26852
- Enhance PBD with a whereExpr/elseStmt field to hold this.
- Start parsing the pattern of let/var decls as a potentially refutable pattern. It becomes
a semantic error to use a refutable pattern without an 'else' (diagnostics not in place yet).
- Change validatePatternBindingDecl to use 'defer' instead of a goto to ensure cleanups on exit.
- Have it resolve the pattern in a PBD, rewriting it from expressions into pattern nodes when valid.
- Teach resolvePattern to handle TypedPatterns now that they can appear (wrapping) refutable patterns.
- Teach resolvePattern to handle refutable patterns in PBD's without initializers by emitting a diagnostic
instead of by barfing, fixing regressions on validation tests my previous patch caused, and fixing
two existing validation test crashers.
Sema, silgen, and more tests coming later.
Swift SVN r26706
