library. We use the same (somewhat broken heuristics), they are
just implemented in another way.
The major functionality change is that previously, .sil files would
auto import "swift" if they started with a non-sil decl. Now they
never do.
Swift SVN r5731
This cleans up some wishy-washy control flow that relied on the uncurryLevel of a type to distinguish ObjC methods from freestanding C functions. While we're here, clean up all the places we use ad-hoc comparison logic on the AbstractCC enum to use switches that properly cover the enum.
Swift SVN r5251
by TranslationUnit. This list existed solely to allow name lookup of
an unbound IdentifierType to know its DeclContext. Instead of indirecting
through this list, just store the DeclContext in the IdentifierType in its
uninitialized state.
This eliminates a really terrible performance fixme about scanning the list,
eliminates the management fiddling around with this list in the parser, and
is generally much cleaner.
Swift SVN r5246
mode for normal .swift files. We basically parse batches of non-sil function
decls, type check them as a batch, then process any SIL functions. This allows
us to have mutually recursive types and other things that are fully sema'd and
that are referenced by SIL functions, without involving SIL functions too
intimately with type checking.
This does mean that SIL functions can't forward reference types, oh well.
Swift SVN r5243
If the name of a func declaration ends in '<' and the following token is an identifier, the '<' has to be a generic angle bracket instead of part of the operator name. Fixes <rdar://problem/13782566>.
Swift SVN r5226
We will handle Swift-function-to-ObjC-block bridging in SILGen as part of general Cocoa-to-Swift type bridging. Temporarily disable building swiftAppKit and tests that exercise block bridging until the new implementation lands.
Swift SVN r5090
Most of this is mechanical, because we weren't actually relying on
byref(heap) for anything. Simplify capture analysis, now that the only
way a variable can have non-fixed lifetime is if it is actually
captured. Fixes <rdar://problem/11247831>.
Swift SVN r5046
Add a SWIFT_FALLTHROUGH macro that expands to [[clang::fallthrough]] for Clang and nothing for other compilers. No functionality change.
Swift SVN r5043
Per Chris's feedback and suggestions on the verbose fix-it API, convert
diagnostics over to using the builder pattern instead of Clang's streaming
pattern (<<) for fix-its and ranges. Ranges are included because
otherwise it's syntactically difficult to add a fix-it after a range.
New syntax:
diagnose(Loc, diag::warn_problem)
.highlight(E->getRange())
.fixItRemove(E->getLHS()->getRange())
.fixItInsert(E->getRHS()->getLoc(), "&")
.fixItReplace(E->getOp()->getRange(), "++");
These builder functions only exist on InFlightDiagnostic; while you can
still modify a plain Diagnostic, you have to do it with plain accessors
and a raw DiagnosticInfo::FixIt.
Swift SVN r4894
For the implicit memberwise struct constructor to be suppressed, one
has to write a constructor with the same parameters (names, types, and
order) as the instance variables of the struct.
Swift SVN r4819
This nests top level PatternBindingDecls (in "main modules") under TopLevelCodeDecls,
instead of having them live in a translation unit. They contain code that is executed,
so they should be in a TLCD.
Swift SVN r4668
Extend the existing "isTerminatorForBraceItemListKind" logic to
handle the special case for top level code, instead of having
weird logic dumped in the middle of parseBraceItemList with no comments.
This logic is still seriously dubious, but at least it is out of the way
instead of dump into already really complex logic.
Swift SVN r4665
Fix array/dictionary literal parsing robustness by consolidating and improving
the parsing of lists in general (tuples/array/dictionary literals, attribute
lists, statement lists, declaration lists, etc).
Missing commas in tuple/array/dictionary literals or declaration attributes
are now detected, reported, and recovered from.
Premature ellipsis in tuples are now detected, reported, and recovered from.
Swift SVN r4631
During name binding, associate func decls with operator decls. When parsing SequenceExprs, look up operator decls to determine associativity and precedence of infix operators. Remove the infix_left and infix_left attributes, and make the infix attribute a simple declared attribute [infix] with no precedence.
Operator decls are resolved as follows:
- If an operator is declared in the same module as the use, resolve to the declaration in the current module.
- Otherwise, import operator declarations from all imported modules. If more than one declaration is imported for the operator and they conflict, raise an ambiguity error. If they are equivalent, pick one arbitrarily.
This allows operator declarations within the current module to override imported declarations if desired or to disambiguate conflicting operator declarations.
I've updated the standard library and the tests. stdlib2 and some of the examples still need to be updated.
Swift SVN r4629
own TLCD. This is important to preserve the ordering of stmt and expr w.r.t.
PatternBindingDecls that initialize the decls.
We keep the BraceStmt wrapping it to make it more similar to other decls
though.
Swift SVN r4626
Unfortunately, this regresses the repl when expressions like (1,2) are entered. This is because the repl is violating some invariants (forming dags out of ASTs, making ASDAG's which upset the type checker). I'm going to fix this next, but can't bring myself to do it in the same commit.
Swift SVN r4617
At the top level, if 'operator' is followed by 'infix', 'prefix', or 'postfix', consider it a contextual keyword, and parse an operator decl following it that looks like:
operator {infix|postfix|prefix} <+> {
attributes…
}
Prefix and postfix operator decls currently admit no attributes. Infix operators have 'associativity {left|right|none}' and 'precedence <int>' attributes.
This patch implements parsing for operator declarations but does not yet attach the declared attributes to func decls for the operators.
Swift SVN r4596
Now that we enforce semicolon or newline separation between statements, we can relax the whitespace requirements on '(' and '[' tokens. A "following" token is now just a token that isn't at the start of a line, and any token can be a "starting" token. This allows for:
a(b)
a (b)
a[b]
a [b]
to parse as applications and subscripts, and:
a
(b)
a
[b]
to parse as an expr followed by a tuple or an expr followed by a container literal.
Swift SVN r4573
Implement switch statements with simple value comparison to get the drudge work of parsing and generating switches in place. Cases are checked using a '=~' operator to compare the subject of the switch to the value in the case. Unlike a C switch, cases each have their own scope and don't fall through. 'break' and 'continue' apply to an outer loop rather to the switch itself. Multiple case values can be specified in a comma-separated list, as in 'case 1, 2, 3, 4:'. Currently no effort is made to check for duplicate cases or to rank cases by match strength; cases are just checked in source order, and the first one wins (aside from 'default', which is branched to if all cases fail).
Swift SVN r4359
If a REPL input parses to an expression, bind it to the next available variable 'r<n>', and print the result as if it were a name binding. Don't bind a variable if the expression consists of a lone DeclRef, and don't print the binding if it has void type.
Swift SVN r4201
Import C enumeration types as either structs wrapping the underlying
integral type (when the C enumeration type has a name) or as the
underlying integral type (when the C enumeration type has no
name). The structs have a constructor from the underlying integral
type, so one can write, e.g., NSStringCompareOptions(0) to get a
zero-valued enumeration.
Enumerators are imported as a global read-only properties.
Once oneofs start to work, we'll have a way to map some enumeration
types to oneofs, either via a Clang attribute or by sniffing out
NS_ENUM (most likely both).
Once we have static data members of structs working, we'll replace the
global constants with prefix-stripped static variables within the
struct, so we can use ".foo" notation with them.
Once we have constant declarations, we'll map to those instead of
properties.
We can add |, &, and ~ operations are part of
<rdar://problem/13028799> and have not yet been implemented.
Fixes <rdar://problem/13028891>.
Swift SVN r3945
In Swift the "in" keyword is really a form of punctuation, and highly
context specific punctuation at that. It never begins a statement, nor
does the grammar require it be statement keyword. The grammar also
doesn't use it outside of for-each loops, and its use within a for-each
loop is highly unambiguous.
Thanks to Chris for the performance related feedback. This improves the
performance of getter/setter parsing as well.
Swift SVN r3880
Dave noted that he's trying to scrub the parser codebase of wishy-washy 'isAnyLParen' and 'isAnyLBrace' calls by consistently lexing opening bracket tokens correctly to begin with. Since currently only 'super' and 'constructor' need to be lexed like identifiers for expression syntax (and, in the future, 'this' and 'This' when those become keywords), mark them as a special kind of 'identifier keyword' in Tokens.def and roll back some of the changes I made to make parsing other decls support either token.
Swift SVN r3848
Opening brackets after a keyword have to lex as l_paren_call or l_square_subscript in order for expressions like 'super.constructor()' or 'super[i]' to parse. While we're here, let's move the keyword and punctuator list to a metaprogrammable Tokens.def header too. Update decl and stmt parsers to use 'isAnyLParen' so that, e.g., 'constructor(' and 'constructor (' both work as before.
Swift SVN r3846
The lexer now models tuples, patterns, subscripting, function calls, and
field access robustly. The output tokens are now better named as well:
l_paren and l_paren_call, and l_square and l_square_subscript. It
should be much more clear now which one to use. Also, the use of
l_paren or l_square will not arbitrarily flip flop if the token before
it is a keyword or if the token before it was the trailing ']' of an
attribute list. Similarly, tuples will always cause the lexer to produce
l_paren, regardless if the user typed '((x,y))' or '( (x,y))'.
When we someday add array literals, the right token is now naturally
falling out of the lexer.
Swift SVN r3840
This requires a gross but simple contract between pattern parsing and C
for loop parsing where pattern parsing will gracefully back out if and
only if we have a potential C for loop pattern AND assignment is
detected in the pattern (which isn't otherwise allowed outside of the
context of func decls).
If we ever want "for (((;;)))" to work, then this we'll need to
implement the fully general arbitrary token lookahead. But for now, the
common C style "just works".
Swift SVN r3831
Only functions support default values in their patterns. To quote: "Within a
function signature, patterns may also be given a default-value expression."
In other words, only functions are allowed default values.
This fixes: 13057022 "var (x : Int = 123, y : Int = 456)" doesn't init x and y
Swift SVN r3829
