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
long as the inner argument names are unique, the different chunks can be referred
to in the definition. There is still some problem with calling these, but that
will be resolved by declaration based invocation rules when they are available.
Swift SVN r13750
clients to either go through the new parseExpr (which is never "basic")
or the existing parseExprBasic entrypoint if they don't want trailing
closures.
Swift SVN r13724
TuplePattern::createSimple. Also, mark the namedpattern implicit, since
it is. Add an example of rdar://15993514 using non-trivial types.
NFC.
Swift SVN r13695
and add it to the release notes. Now you can elide the name on the second (or later) selector
chunk in a func declaration, and it gets implicitly named the same as the selector chunk.
This requires a speculative parse in the general case, but in the common cases
we don't need that.
Swift SVN r13691
function. Parse inout as a contextual keyword there, shoving it into the
TypedPattern (instead of introducing a new kind of Pattern). This enables
us to parse, sema, and irgen the new '@-less' syntax for inout.
Swift SVN r13559
function, which is fully general w.r.t. different pattern structures that can
happen in the first argument of a selector-style function. Notably, this
handles VarPatterns, so we can now use var/let in selector-style functions,
resolving rdar://15814933.
Swift SVN r12322
substantially reimplementing it. AFAICT, this was duplicated out because
we need to build two parallel patterns: one for the argument pattern and
one for the body pattern. Instead of building these in parallel, just parse
the body pattern as normal, then use a simple ASTWalker to rerewrite a clone
of the body pattern for the argument context.
One bad thing about this patch is that it changes code completion within the
type portion of a selector-style argument list. I don't understand this well
enough to know how to fix it, so I disabled the test for now and will follow
up offline with smart people that know this stuff.
This is required (but not sufficient) to resolve rdar://15814933.
Swift SVN r12321
'let' values (so they are immutable and don't get a box, etc). Add a flag to
the swift compiler that turns the bulk of function arguments into lets, but
don't set it yet.
Swift SVN r12274
Switch some diagnostic text from 'static' over to 'type' to make
things easier, and fix up some parsing issues with selector-style
declarations found by doing this. NFC
Swift SVN r12030
This allows them to appear in argument lists of functions, enabling behavior
like this:
func test_arguments(a : Int, var b : Int, let c : Int) {
a = 1 // ok (for now).
b = 2 // ok.
c = 3 // expected-error {{cannot assign to the result of this expression}}
}
Swift SVN r11746
