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
* replaced yet another variant of isWhitespace with the version from
clang/Basic/CharInfo.h. The major difference is that our variant used to
consider '\0' whitespace.
* made sure that we don't construct StringRefs that point after the end of the
buffer. If the buffer ends with "#", then MemoryBuffer will only guarantee
that there is one additional NUL character. memcmp(), OTOH, is allowed to
access the complete span of the provided memory. I colud not actually get
this to crash on OSX 10.10, but I do remember similar crashes we fixed in Clang.
* added checks to reject extra tokens at the end of the build configuration
directive -- see tests, that code used to compile without diagnostics. The
lexer tried to do this, but in a self-referential way -- by checking the
NextToken variable (which is actually the previous token, when viewed from
the point of lexImpl()). The checks I added are a little too strict, they
reject comments at the end of the directive, but at least we don't accept
strange constructs. Allowing comments would not be hard, just requires
factoring out lexer's routines to skip comments so that they accept a pointer
to the buffer and return the comment end point. Filed
<rdar://problem/16301704> Allow comments at the end of bulid configuration directives
for that.
Found by inspection... I was grepping the codebase for 'isWhitespace'.
Swift SVN r14959
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
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
Track whether an identifier token is an escaped identifier token so that 'isContextualKeyword' can say "no" when an identifier is escaped.
Swift SVN r14712
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
Lex a backtick-enclosed `[:identifier_start:][:identifier_cont:]+` as an identifier, even if it's a Swift keyword. For now, require that the escaped name still be a valid identifier, keyword collisions notwithstanding. (We could in theory allow an arbitrary string, but we'd have to invent a mangling for non-identifier characters and do other tooling which doesn't seem productive.)
Swift SVN r14671
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
We can attach comments to declarations. Right now we only support comments
that precede the declarations (trailing comments will be supported later).
The implementation approach is different from one we have in Clang. In Swift
the Lexer attaches the comments to the next token, and parser checks if
comments are present on the first token of the declaration. This is much
cleaner, and faster than Clang's approach (where we perform a binary search on
source locations and do ad-hoc fixups afterwards).
The comment <-> decl correspondence is modeled as "virtual" attributes that can
not be spelled in the source. These attributes are not serialized at the
moment -- this will be implemented later.
Swift SVN r14031
attributes on the didSet/willSet declaration. This fixes:
<rdar://problem/16076758> Attributes on didSet/willSet + property initializer completely confuse the parser
Swift SVN r13936
outside of debugger-support mode. Rip out the existing special-case
code when parsing expr-identifier.
This means that the Lexer needs a LangOptions. Doug and I
talked about just adding that as a field of SourceMgr, but
decided that it was worth it to preserve the possibility of
parsing different dialects in different source files.
By design, the lexer doesn't tokenize fundamentally differently
in different language modes; it might decide something is invalid,
or it might (eventually) use a different token kind for the
same consumed text, but we don't want it deciding to consume more or
less of the stream per token.
Note that SIL mode does make that kind of difference, and that
arguably means that various APIs for tokenizing need to take a
"is SIL mode" flag, but we're getting away with it because we
just don't really care about fidelity of SIL source files.
rdar://14899000
Swift SVN r13896
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
