completion inside computed properties.
Adding tests for willSet/didSet uncovered some crashes while doing code
completion (see FIXMEs), and I will investigate these next.
Partially addresses rdar://15849262
Swift SVN r14338
- Respond to Doug's code review feedback
- Stop hacking around with scopes and use "emplace" to work around RAII in the inactive config case
- Limit use of StringRef on the front-end, in favor of std::string
- Use ArrayRef rather than SmallVector within IfConfigDecl
- Reorder new property declarations on BraceStmt to prevent unnecessary alignment issues
- Update ParseBraceItems to better capture top-level declarations, rather than using token lookahead
Swift SVN r14306
These changes add support for build and target configurations in the compiler.
Build and target configurations, combined with the use of #if/#else/#endif allow
for conditional compilation within declaration and statement contexts.
Build configurations can be passed into the compiler via the new '-D' flag, or
set within the LangOptions class. Target configurations are implicit, and
currently only "os" and "arch" are supported.
Swift SVN r14305
attributes on the didSet/willSet declaration. This fixes:
<rdar://problem/16076758> Attributes on didSet/willSet + property initializer completely confuse the parser
Swift SVN r13936
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
This can be used as, for example
self.init withRed(0.5) green(0.5) blue(0.5) alpha(1.0)
which mimics the declaration. THe same goes for super.
Note that this does not yet support
NSColor.init withRed(0.5) green(0.5) blue(0.5) alpha(1.0)
due to a limitation in the type checker.
Swift SVN r13825
This allows code such as
obj.closure { return 0 } onError { println("error") }
to parse appropriately. The only other functionality change here is
that we no longer allow the use of a trailing closure within the
condition of a C-style for loop, because it did awful things to
recovery. I doubt we'll miss it.
Swift SVN r13823
We don't want to parse the expr-call-suffix as a general
postfix-expression; rather, we only want it when we're directly naming
a method. This doesn't matter so much in the current model, but it
becomes important when we move over to the newer keyword argument model.
Swift SVN r13819
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
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
from the pattern to the scope (it doesn't do other argument
specific stuff like mucking with decl contexts) rename it to
addPatternVariablesToScope, and use it in two more places
in the parser.
Swift SVN r13710
SubscriptDecl is created, then the accessors are installed on it.
This allows us to create the subscript decl before the accessors
have been parsed, allowing us to build the subscript even in invalid
cases (better for later error recovery).
More importantly, this allows us to add it to Decls before calling
parseGetSet, so we can now make parseGetSet add accessors to Decls
without breaking source order (something that deeply upsets the IDE
features).
With all this untangled, we can now remove the 'addAccessorsInOrder'
hack where we parsed the accessors and then later tried to figure out
which order they came for the purpose of linking up the AST: accessors
now work just like everything else.
Swift SVN r13708
all of their generic parameters. This simplifies logic creating them,
allowing us to eliminate all setDeclContext() calls from the parser.
While we're at it, change Parser::addVarsToScope to be a static
function in ParseStmt.cpp and dramatically cut it down since none of
its remaining clients are using most of its capabilities. It needs
to be simplified even further.
Swift SVN r13702
automatically reparent VarDecls in their arg/body patterns and
GenericParameters to themselves. These all have to be created
before the actual context decl is created and then reparented,
so we might as well have the reparenting be done by the decl
itself. This lets us take out some setDeclContext reparenting
loops from around the parser.
I'm sure that there are a lot more places they can be removed
from as well.
NFC.
Swift SVN r13701
set by the parser. Instead of having addVarsToScope grovel through
and find them to do this, just do it directly when parsing the accessors.
Subscripts do this, so vardecls can too.
Swift SVN r13696
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
"@mutating func f()". I'm keeping the @mutating version around
so we can determine what to do with @!mutating.
Also, improve the QoI of mutating related diagnostics.
Swift SVN r13480
with FuncDecls. This allows us to eliminate special case code for handling
self in various parts of the compiler.
This also improves loc info (debug info and AST info) because 'self' now
has a location instead of being invalid.
I also took the opportunity to factor a bunch of places creating self decls
to use similar patterns and less copy and paste code.
Swift SVN r13196
Allow IfStmts and WhileStmts to have as their condition either an expression, as usual, or a pattern binding introduced by 'var' or 'let', which will conditionally bind to the value inside an optional. Unlike normal pattern bindings, these bindings require an in-line initializer, which will be required to be Optional type. Parse variable bindings in this position, and type-check them by requiring an Optional on the right-hand side and unwrapping it to form the pattern type. Extend SILGen's lowering of if and while statements to handle conditionally binding variables.
Swift SVN r13146
mostly to get the brokenness inherent in their current representation out
of my way.
The biggest part of this is that properties in protocols are now always
represented as Computed VarDecls. If you write "var x : Int" in a protocol,
you get an getter FuncDecl. If you write "var x : Int { get}" you get the same
thing. If you write "var x : Int { get set }" then you get a getter and setter
prototype associated with the vardecl.
This then readjusts the various hacks that sort of pass through such things
in SILGen and IRGen, so that we have the same level of hacky support for properties
in protocols.
From the functionality perspective, this enables the { get set } syntax described
in rdar://15827219, and means that "var x : Int" is uniformly treated as read-only
(it was treated as mutable in some cases before). Properties in protocols are
still quite broken though.
Swift SVN r12981
1. Implement parser and sema support for our subscript syntax proposal in
protocols. Now you have to use subscript(..) { get } or {get set} to
indicate what you want. I suspect that the syntax will evolve, but at
least we can express what we need now.
2. Change the representation of SubscriptDecls in protocols to make
(empty) funcdecls for the getter and setter. This guarantees that
every subscript has at least a getter.
Swift SVN r12555
Thanks to the way we've set up our diagnostics engine, there's not actually
a reason for /everything/ to get rebuilt when /one/ diagnostic changes.
I've split them up into five categories for now: Parse, Sema, SIL, IRGen,
and Frontend, plus a set of "Common" diagnostics that are used in multiple
areas of the compiler. We can massage this later.
No functionality change, but should speed up compile times!
Swift SVN r12438
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
The parser shouldn't be diagnosing such semantic constraints. While
I'm here, allow definitions on functions in protocols (they're ignored
for now).
Swift SVN r11223
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
