Loosen restrictions on where #available() can appear in IfStmt guards and refine the
context for guard StmtConditionElements following an availability check.
This enables #available() to be combined with if let optional binding:
if #available(iOS 8.0, *),
let x = someIOS8API() {
// Do more iOS 8 stuff
}
and
if let x = someIOS7API() where #available(iOS 8.0, *),
let y = someIOS8API() {
// Do more iOS 8 stuff
}
Swift SVN r28096
Now we bind the defer body into a ClosureExpr and emit it at the point of
the defer. At any exit points out of the controlled region, we emit a call
to the closure.
This should cover any problems where expressions cannot be emitted multiple times.
However, this is dramatically more complex than the obvious implementation, so I
hope this patch can be reverted.
Swift SVN r27767
Change all uses of "do { ... } while <cond>" to use "repeat" instead.
Rename DoWhileStmt to RepeatWhileStmt. Add diagnostic suggesting change
of 'do' to 'repeat' if a condition is found afterwards.
<rdar://problem/20336424> rename do/while loops to repeat/while & introduce "repeat <count> {}" loops
Swift SVN r27650
Previously some parts of the compiler referred to them as "fields",
and most referred to them as "elements". Use the more generic 'elements'
nomenclature because that's what we refer to other things in the compiler
(e.g. the elements of a bracestmt).
At the same time, make the API better by providing "getElement" consistently
and using it, instead of getElements()[i].
NFC.
Swift SVN r26894
This patch also introduces some SILGen infrastructure for
dividing the function into "ordinary" and "postmatter"
sections, with error-handling-like stuff going into the
final section. Currently, this is largely undermined by
SILBuilder, but I'm going to fix that in a follow-up.
Swift SVN r26422
For now, we assume that 'while' after the braces starts
a do/while rather than being an independent statement.
We should disambiguate this, or better, remove do/while.
Tests later.
Swift SVN r26079
This doesn't allow 'continue' out of an if statement for the same reason we don't
allow it on switch: we'd prefer people to write loops more explicitly.
Swift SVN r25565
Fix a crash in coverage when a while's condition consists only of let
clauses. This degrades to simply not showing the coverage for the
condition in that case for now, since we don't handle Patterns yet.
Swift SVN r25456
This adds the -profile-coverage-mapping option to swift, and teaches
SILGenProfiling to generate mappings from source ranges to counters.
Swift SVN r25266
if-let statements (also while and var, of course) that include multiple bindings
and where clauses.
SILGen support still remains, it currently just asserts on the new constructs.
Swift SVN r24239
llvm::Optional lives in "llvm/ADT/Optional.h". Like Clang, we can get
Optional in the 'swift' namespace by including "swift/Basic/LLVM.h".
We're now fully switched over to llvm::Optional!
Swift SVN r22477
This restructures IfConfigDecl/Stmt to be a list of clauses controlled
by a condition. This makes it straight-forward to drop in #elseif support.
While I'm in here, this patch moves checking for extraneous stuff at the
end of the #if line from the lexer to the parser. This means that you can
now put a comment on the same line as a #if/#else/#elseif/#endif.
Swift SVN r16912
Right now you can 'break' out of a labeled switch statement, but unlabeled
break retains its previous semantics of breaking out of the nearest loop.
Swift SVN r16616
LabeledStmt that they target: have sema fill this in, and make silgen respect it.
NFC, because this was specifically written to behave the same as before (e.g. no
break out of switches).
Swift SVN r16610
improves location information to track the label location in the AST. We
don't currently track the location of the colon, but that would be trivial
to drop in if it is interesting.
Swift SVN r16608
- 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
The name Stream didn't seem to be working out as intended; we kept
gravitating back to calling it Generator, which is precedented in other
languages. Also, Stream seems to beg for qualification as Input or
Output. I think we'd like to reserve Stream for things that are more
bulk-character-API-ish.
Swift SVN r13893
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
A few places in the core compiler were referring to instances of the
Sequence protocol as "Containers". The "Indexable" protocol will soon
be renamed "Container," so eliminate this potential confusion
Swift SVN r11944
This is step 1 of implementing the new Container/Sequence/Stream
protocols. See test/Prototypes/Container.swift for the complete picture
of where this is headed.
Swift SVN r11924
We still want to allow line wrapping, so only issue the warning when the indentation of the expression and the return keyword is the same.
radar://11945406
Swift SVN r9984
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
Rewrite ForEachStmt SILGen to use the Optional intrinsics with the Generator.next method to iterate through sequences, and kill off the Enumerator path in Sema. Cut over 'EnumeratorType.Element' requirements to instead require 'GeneratorType.Element' in the stdlib.
There are a couple of bugs remaining that need follow-up work. There appears to be a bug in nested enum layout (e.g. T??) that's causing test/Interpreter/enum to break; I'll investigate and fix. There's also a lingering type-checker bug with inferred associated types that causes them to fail requirement checks <rdar://problem/15172101>, which I think Doug needs to look into.
Swift SVN r9017
Set up (currently ignored by SILGen) variable bindings and 'next' method invocations we'll be able to use to cut over to Generator-based iteration.
Swift SVN r9002
Definitions for derived protocol conformances will need to be able to create implicit statements free of the rules formerly hardcoded in Stmt::isImplicit. This also follows Dmitri and Argyrios's "implicit" improvements to the other AST hierarchies.
Swift SVN r8876
ForStmt::Cond is already a NullablePtr<>. This patch changes
ForStmt::Initializer and ForStmt::Increment to be NullablePtr. Otherwise it
looks like Cond can be null, while Initializer and Increment can not.
Swift SVN r7265
