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
var decls. I was originally intending to use this for argument lists, but I
don't think that's a great direction to go anymore.
In any case, it seems uncontroversial to enforce immutability on foreach
enumation patterns, so I did that (see testcase)
Swift SVN r11124
are not settable (like get-only ones). Set the 'isLet' bit in various
places, but not the particularly interesting or useful places yet.
Swift SVN r11121
Also, improve error recovery for new-syntax attributes.
This means that we now compile the testcase into:
t.swift:3:16: error: unknown attribute 'xyz'
var x : () -> @xyz Int
^
t.swift:6:16: error: unknown attribute 'xyz'
func foo() -> @xyz Int {
^
instead of:
t.swift:4:15: error: expected type for function result
func foo() -> @xyz Int {
^
t.swift:4:14: error: consecutive statements on a line must be separated by ';'
func foo() -> @xyz Int {
^
;
t.swift:4:16: error: unknown attribute 'xyz'
func foo() -> @xyz Int {
^
t.swift:7:1: error: expected declaration
^
this is part of rdar://15183765
Swift SVN r9260
Parse '_' as a DiscardAssignmentExpr. Type-check it as an lvalue, and check that it only appears in the LHS of AssignExprs. During matching pattern resolution, convert it into an AnyPattern. In SILGen, when we see '_' in the LHS of an assignment, ignore the corresponding RHS rvalue.
Swift SVN r8848
Argument patterns create pseudo-named patterns, so make them implicit and ignore them when scanning for explicit source information.
Also make sure that the clang importer sets the HasSelectorStyleSignature bit appropriately.
Swift SVN r8803
Implement the new rules for mapping between selector names and
constructors. The selector for a given constructor is formed by
looking at the names of the constructor parameters:
* For the first parameter, prepend "init" to the parameter name and
uppercase the first letter of the parameter name. Append ':' if
there are > 1 parameters or the parameter has non-empty-tuple type.
* For the remaining parameters, the name of each parameter followed
by ':'.
When a parameter doesn't exist, assume that the parameter name is the
empty string.
And, because I failed to commit it separately, support selector-style
declarations of constructor parameters so that we can actually write
constructors nicely, e.g.:
// selector is initWithFoo:bar:
constructor withFoo(foo : Foo) bar(bar : Bar) { ... }
Swift SVN r8361
