When a function declaration has a body, its source range ends at the
closing curly brace, so it includes the `throws(E)`. However, a
protocol requirement doesn't have a body, and due to an oversight,
getSourceRange() was never updated to include the extra tokens
that appear after `throws` when the function declares a thrown
error type. As a result, unqualified lookup would fail to find a
generic parameter type, if that happened to be the thrown type.
Fixes rdar://problem/143950572.
Single-expression closures have always been traversed differently
from multi-statement closures. The former were traversed as if the
expression was their only child, skipping the BraceStmt and implicit
return, while the later was traversed as a normal BraceStmt.
Unify on the latter treatment, so that traversal
There are a few places where we unintentionally relied on this
expression-as-child behavior. Clean those up to work with arbitrary
closures, which is an overall simplification in the logic.
InterpolatedStringLiteralExpr has a TapExpr, which contains a BraceStmt
containing the builder CallExprs to the builder appendInterpolation /
appendStringLiteral methods used to construct the final string. This is all
implementation detail, but the BraceStmt wasn't marked implicit and had a valid
(but incorrect) SourceRange, so the document structure request treated it as
any other BraceStmt and made a structure node for it. The invalid range ended
up tripping an assertion in the document structure walker in swift-ide-test.
This patch corrects the BraceStmts produced by interpolated strings to be
marked implicit and have the correct range, and also updates ModelASTWalker to
skip over the internal details of interpolated strings when walking them (the
CallExprs were also being emitted).
When looking for the SyntaxNode corresponding to a type attribute (like
@escaping), ModelASTWalker would look for one whose range *started* at the type
attribute's source location. It never found one, though, because the
SyntaxNode's range included the @, while the type attribute's source location
pointed to the name *after* the @.
ModelASTWalker was previously constructing SyntaxNodes for EnumElementDecls
manually when visiting their associated EnumCaseDecl so that they would appear
as children rather than siblings. It wasn't actually walking these nodes
though, so missed handling some things, e.g. closures passed as default
argument values. These were also still being visited later, and because the
first visit consumed all the associated TokenNodes, this was triggering an
assertion due to the associated TokenNodes not matching expectations.
* Handle sequence expression at call argument position
* Set the sequence expression as the parent when walking into its sub
expressions.
* Correctly call walkToExprPost() to the sequence expression.
rdar://problem/47603866 / https://bugs.swift.org/browse/SR-9776
Explict cast expressions (i.e. 'as', 'as!`, 'as?', and 'is') appear twice in
'SequenceExpr'. For instance, 'a as B' is parsed as:
(sequence_expr
(unresolved_declref_expr name='a')
(coerce_expr writtenType='B')
(coerce_expr writtenType='B'))
This patch prevents ModelASTWalker from walking into them twice.
rdar://problem/43135727
Parameters (to methods, initializers, accessors, subscripts, etc) have always been represented
as Pattern's (of a particular sort), stemming from an early design direction that was abandoned.
Being built on top of patterns leads to patterns being overly complicated (e.g. tuple patterns
have to have varargs and default parameters) and make working on parameter lists complicated
and error prone. This might have been ok in 2015, but there is no way we can live like this in
2016.
Instead of using Patterns, carve out a new ParameterList and Parameter type to represent all the
parameter specific stuff. This simplifies many things and allows a lot of simplifications.
Unfortunately, I wasn't able to do this very incrementally, so this is a huge patch. The good
news is that it erases a ton of code, and the technical debt that went with it. Ignoring test
suite changes, we have:
77 files changed, 2359 insertions(+), 3221 deletions(-)
This patch also makes a bunch of wierd things dead, but I'll sweep those out in follow-on
patches.
Fixes <rdar://problem/22846558> No code completions in Foo( when Foo has error type
Fixes <rdar://problem/24026538> Slight regression in generated header, which I filed to go with 3a23d75.
Fixes an overloading bug involving default arguments and curried functions (see the diff to
Constraints/diagnostics.swift, which we now correctly accept).
Fixes cases where problems with parameters would get emitted multiple times, e.g. in the
test/Parse/subscripting.swift testcase.
The source range for ParamDecl now includes its type, which permutes some of the IDE / SourceModel tests
(for the better, I think).
Eliminates the bogus "type annotation missing in pattern" error message when a type isn't
specified for a parameter (see test/decl/func/functions.swift).
This now consistently parenthesizes argument lists in function types, which leads to many diffs in the
SILGen tests among others.
This does break the "sibling indentation" test in SourceKit/CodeFormat/indent-sibling.swift, and
I haven't been able to figure it out. Given that this is experimental functionality anyway,
I'm just XFAILing the test for now. i'll look at it separately from this mongo diff.
Make the following illegal:
switch thing {
case .A(var x):
modify(x0
}
And provide a replacement 'var' -> 'let' fix-it.
rdar://problem/23172698
Swift SVN r32883
into the body of the for statement. Instead of ripping the body of the closureexpr
out and putting it into the C Style for, wrap up the closureExpr into a call. This
avoids breaking AST invariants because the ClosureExpr will be the DeclContext for
anything inside of it.
This fixes <rdar://problem/21679557> compiler crashes on "for{{"
... which was Practical Swift's shortest crasher.
Swift SVN r29916
includes a number of QoI things to help people write the correct code. I will commit
the testcase for it as the next patch.
The bulk of this patch is moving the stdlib, testsuite and validation testsuite to
the new syntax. I moved a few uses of "as" patterns back to as? expressions in the
stdlib as well.
Swift SVN r27959
Change all uses of "do { ... } while <cond>" to use "repeat" instead.
Rename DoWhileStmt to RepeatWhileStmt. Add diagnostic suggesting change
of 'do' to 'repeat' if a condition is found afterwards.
<rdar://problem/20336424> rename do/while loops to repeat/while & introduce "repeat <count> {}" loops
Swift SVN r27650
Previously, a multi-pattern var/let decl like:
var x = 4, y = 17
would produce two pattern binding decls (one for x=4 one for y=17). This is convenient
in some ways, but is bad for source reproducibility from the ASTs (see, e.g. the improvements
in test/IDE/structure.swift and test/decl/inherit/initializer.swift).
The hardest part of this change was to get parseDeclVar to set up the AST in a way
compatible with our existing assumptions. I ended up with an approach that forms PBDs in
more erroneous cases than before. One downside of this is that we now produce a spurious
"type annotation missing in pattern"
diagnostic in some cases. I'll take care of that in a follow-on patch.
Swift SVN r26224
