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
We were never handling this correctly, and default arguments are checked along with the method body.
In some cases where no further validation was necessary (such as when the default argument was a literal value),
the compiler would let this slip through but in others this would cause a crash. (rdar://problem/16476405)
Swift SVN r15736
Allow a form of 'case is T' that matches the cast result to a subpattern, 'case <pattern> as T'. This exposes an issue in switch destructuring with casting into complex class hierarchies <rdar://problem/16401831> but works for common cases.
Swift SVN r15396
we were previously lookahead parsing the argument list of a closure
literal as a tuple-type, when we should be doing so as a tuple-pattern.
This doesn't permit some pattern stuff, such as var/let on arguments.
Implement pattern parsing lookahead and use it.
Swift SVN r15350
Parse function declarations with the form
func murder inRoom(room: Int) weapon(Int) {}
where the function name ("murder") is separated from the parameter
names. This is the same style used in initializers, i.e.,
init withCString(cstr: CString) encoding(Encoding)
Swift SVN r15140
This means that we accept type attributes in a much broader
range of places where we previously required a <type>. <type>
was already a production that demanded a grammatically
unconstrained context because of all the possible continuations;
reducing the number of independent productions makes it easier
to choose one and thus not accidentally limit the range of
possible types parsed.
In particular, we want to be able to parse @unchecked T? pretty
much anywhere you can write a type.
Swift SVN r14912
Make the name lookup interfaces all take DeclNames instead of identifiers, and update the lookup caches of the various file units to index their members by both compound name and simple name. Serialized modules are keyed by identifiers, so as a transitional hack, do simple name lookup then filter the results by compound name.
Swift SVN r14768
Collect the identifiers for the selector pieces we parsed and use them to build a compound DeclName for the func decl. Currently this only manifests when __FUNCTION__ is used inside a selector-style function definition, where we now correctly produce the compound 'foo:bar:' name.
Swift SVN r14717
Add __FUNCTION__ to the repertoire of magic source-location-identifying tokens. Inside a function, it gives the function name; inside a property accessor, it gives the property name; inside special members like 'init', 'subscript', and 'deinit', it gives the keyword name, and at top level, it gives the module name. As a bit of future-proofing, stringify the full DeclName, even though we only ever give declarations simple names currently.
Swift SVN r14710
Implement several rules that determine when an identifier on a new
line is a continuation of a selector-style call on a previous line:
- In certain contexts, such as parentheses or square brackets, it's
always a continuation because one does not split statements in
those contexts;
- Otherwise, compare the leading whitespace on the line containing
the nearest enclosing statement or declaration to the leading
whitespace for the line containing the identifier.
The leading whitespace for a line is currently defined as all space
and tab characters from the start of the line up to the first
non-space, non-tab character. Leading whitespace is compared via a
string comparison, which eliminates any dependency on the width of a
tab. One can run into a few amusing cases where adjacent lines that
look indented (under some specific tab width) aren't actually indented
according to this rule because there are different mixes of tabs and
spaces in the two lines. See the bottom of call-suffix-indent.swift
for an example.
I had to adjust two test cases that had lines with slightly different
indentation. The diagnostics here are awful; I've made no attempt at
improving them.
Swift SVN r13843
"parameter list" instead of "tuple argument". Fix a potential crash I
introduced by making an assumption about default initialized implied name
parameters being the only thing in parens.
Swift SVN r13813
This allows us to use implicit names in protocols and asm name functions, as well
as for the first chunk of selectors. This feature is particularly useful for
delegate methods.
Swift SVN r13751
