a vararg subpattern of a TuplePattern should be a TypedPattern
Check for a vararg subpattern to be a typed pattern seemed to be missing in closure arguments parsing.
Swift SVN r24733
Curried function parameters (i.e., those past the first written
parameter list) default to having argument labels (which they always
have), but any attempt to change or remove the argument labels would
fail. Use the fact that we keep both the argument labels and the
parameter names in patterns to generalize our handling of argument
labels to address this problem.
The IDE changes are due to some positive fallout from this change: we
were using the body parameters as labels in code completions for
subscript operations, which was annoying and wrong.
Fixes rdar://problem/17237268.
Swift SVN r24525
This preserves more of source info (e.g. API name location) and simplifies things since
we don't have to construct ParamDecls for the unnamed parameters later on.
Swift SVN r17828
Subscript declarations were still encoding the names of index
variables in the subscript type, which unintentionally made them
keyword arguments. Bring subscript declarations into the modern day,
using compound names to encode the subscript argument names, which
provides consistency for the keyword-argument world
<rdar://problem/14462349>. Note that arguments in subscripts default
to not being keyword arguments, which seems like the right default.
We now get keyword arguments for subscripts, so one can overload
subscripts on the names of the indices, and distinguish at the call
site. Under -strict-keyword-arguments, we require strictness here as well.
The IRGen/IDE/SILGen test updates are because the mangling of common
subscripts changed from accidentally having keyword arguments to not
having keyword arguments.
Swift SVN r17393
Introduce a model where an argument name is a keyword argument if:
- It is an argument to an initializer, or
- It is an argument to a method after the first argument, or
- It is preceded by a back-tick (`), or
- Both a keyword argument name and an internal parameter name are
specified.
Provide diagnostics Fix-Its to clean up cases where the user is
probably confused, i.e.,
- "_ x: Int" -> "x: Int" where "x" would not have been a keyword
argument anyway
- "x x: Int" -> "`x: Int"
This covers the compiler side of <rdar://problem/16741975> and
<rdar://problem/16742001>.
Update the AST printer to print in this form, never printing just
a type for a parameter name because we're also going to adopt
<rdar://problem/16737312> and it was easier to move the tests once
rather than twice.
Standard library and test updates coming separately.
Swift SVN r17056
Part of <rdar://problem/16742001>. At the moment, this is just a
parsing thing, because argument names are still API by default
anyway.
Swift SVN r16991
The selector-style parameter parsing code is going away "soon", but we
still need to prop it up a bit longer. Hence, I don't feel too bad
about the Parser-level state I'm using in this hack to make it happen.
With that change, we can now establish two important invariants in the
AST:
- Only parameters (ParamDecl or GenericTypeParamDecl) can have their
DeclContexts changed. Everything else comes into being in the
correct context.
- All of the parameters in a function/constructor/closure/etc. are
described by ParamDecls, not just VarDecls.
Swift SVN r16593
This means we get ParamDecls rather than VarDecls. Additionally, we
parse both API names and parameter names, although the API names
aren't currently useful. As part of this, loosen up the tentative
parsing that disambiguates between a tuple and a closure
parameter-clause.
Swift SVN r16585
Use this node to capture the argument name and its source location in
the AST. We're only building these in one place at the moment; the
rest will be updated soon.
Swift SVN r16581
Extend parsing of the new function syntax, where both the argument
(API) and parameter (internal) name are specified prior to the colon,
to initializers.
Swift SVN r16311
Parse the new function syntax, which allows both the argument (API)
and parameter (internal) name to be specified prior to the colon
within each parameter. Don't re-use the existing pattern-parsing
logic. Rather, implement a new (far simpler) parser for this purpose,
then map from its simple data structures to ArgParams and BodyParams
as we're used to.
There are a number of caveats here:
- We no longer have the ability to use patterns for parameters in
function declarations. The only place this really has an impact is
that it makes the ~> hack in the standard library even uglier.
- This exposed some issues with code completion with generic
parameters that need to be investigated.
- There's still some work to be done to improve recovery when things
parse poorly within a parameter list; there are some XFAILs to deal
with that.
I'll address the last two issues with follow-up commits.
Swift SVN r15967
Swift will use the basename + argument names formulation for
names. Update the DeclName interfaces, printing, and __FUNCTION__ to
use the method syntax.
We'll still need to rework the "x.foo:bar:wibble:" syntax; that will
come (significantly) later.
Swift SVN r15763
