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
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
