- 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
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 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
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
down next to case statement parsing logic since it is specific to
it. It looks like we can't fully eliminate this right now, because
patterns in case statements are parsed generally as expr patterns
and sema'd into something more useful later, too late for setting
variables in scopes. The parsing logic could be improved here, but
I'm not going to work on this.
As a driveby, improve error recovery when type checking of case
statement patterns fails by marking the decls inside of them as
invalid.
Swift SVN r13712
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
now that they are implicitly updated. This exposes two things:
1) we're unncessarily serializing selfdecls in ctors and dtors.
2) The index pattern of a SubscriptDecl has no sensible DeclContext that
owns variables in it.
I'll deal with the first tomorrow, I'm not sure what to do with
the second one.
Swift SVN r13703
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
for loop that walks the pattern variables and sets them up.
Move addVarsToScope to ParseStmt.cpp which is what is left
using it.
Add a new "addAccessorsInOrder" helper to add the get/set
accessors to the Decls tree in the right order.
Swift SVN r13697
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
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
arguments. Until we have @inout methods on structs, we can't mark anything
that can be address-exposed. This temporarily regresses a few testcases,
but they will come back later.
Swift SVN r11359
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
The contexts for which we set the DisallowStoredVar bit, currently enums and extensions, can both (theoretically) support static variables, so change PD_DisallowStoredVar to PD_DisallowStoredInstanceVar, and allow static vars to be declared in these contexts.
Swift SVN r10350
Previously, the Parser and BranchStmt typedef-ed ExprStmtOrDecl as a pointer union. Using typedef made the objects compatible, but did not allow us to extend the type with helper methods, such as getSourceRange(), which is something you can get on all of the AST objects. This patch introduces ASTNode that subclasses from PointerUnion and is used by both parser and BranchStmt.
Swift SVN r9971
I tried hard find all references to 'func' in documentation, comments and
diagnostics, but I am sure that I missed a few. If you find something, please
let me know.
rdar://15346654
Swift SVN r9886
