They had already diverged even before my last commit. Let's not have that
happen again!
This re-fixes code completion for bindings declared in top-level guard
statements.
More rdar://problem/21928533
Swift SVN r30525
For now, just update NameLookup's FindLocalVal to use a
VisibleDeclConsumer just like lookupVisibleDecl().
A subsequent patch will continue removing duplicated code
now that this is place.
This fixes compiler crashers where we were not handling
declarations with duplicate names (which of course is an
error, diagnosed elsewhere).
Swift SVN r29913
Make sure we build the CatchStmt and DoCatchStmt AST nodes when
code-completing inside the body of a catch so that we can complete the
bindings from the catch.
It's often a good idea to early-exit once we see a code completion
token, but not when we skip building an AST node that provides variable
bindings. In code completion, we don't have Scope-based lookup, and
rely on having reachable AST nodes for patterns so that we can dig the
out the bindings we need.
Also extend the pattern checking to handle "IsPattern", since we
apparently weren't handling "let x as Foo", and that affects all complex
catch patterns because of an implicit "as ErrorType" or explicit
"as NSError".
rdar://problem/21116164
Swift SVN r29070
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
After this change,
extension P where WHERE1 { final func foo() {} }
extension P where WHERE2 { final func bar() { #^COMPLETE_HERE^#
will complete foo() if and only if WHERE2 is complatible with WHERE1.
Swift SVN r27480
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 introduces a new kind of pattern for matching bool literals, i.e. true and false. Essentially, it is very similar to a pattern for matching enum elements, but simpler. Most of the code is just a boiler plate code copy/pasted from the code for enum element patterns. The only different thing is the emitBoolDispatch function, which emits a SIL code for matching bools.
With this patch, we don't get any false non-exhaustive switch diagnostics for switches on bools anymore. And we have a lot of radars complaining about it. For example rdar://16514545 and rdar://20130240.
Note, that this patch fixes the non-exhaustive switch diagnostics without changing the internal representation of bools. Implementing bool as an enum would have the same effect when it comes to these diagnostics and we would get this diagnostics fix for free, i.e. without any code committed here. But implementing bools-as-enums is an ongoing work and I'm investigating its performance implications. If we become confident that bool-as-enum does not have a negative impact on performance and decide to merge it, then we can revert this patch as it would not be necessary anymore. But if we decide to skip the enum-as-bool approach to its performance issues, then we would have at least fixed the false non-exhaustive diagnostics for bools by means of this patch.
Swift SVN r26650
getImportedModules is the canonical way to get imports, whether private,
public, or both. This is especially true now that we have more flags
for SourceFile imports that really shouldn't be consumed by anyone
outside of SourceFile.
In this same vein, provide addImports instead of setImports, since imports
are always additive.
No visible functionality change.
Swift SVN r26634
Currently a no-op, but effective access for entities within the current
module will soon need to take testability into account. This declaration:
internal func foo() {}
has a formal access of 'internal', but an effective access of 'public' if
we're in a testable mode.
Part of rdar://problem/17732115 (testability)
Swift SVN r26472
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
Previously, a multi-pattern var/let decl like:
var x = 4, y = 17
would produce two pattern binding decls (one for x=4 one for y=17). This is convenient
in some ways, but is bad for source reproducibility from the ASTs (see, e.g. the improvements
in test/IDE/structure.swift and test/decl/inherit/initializer.swift).
The hardest part of this change was to get parseDeclVar to set up the AST in a way
compatible with our existing assumptions. I ended up with an approach that forms PBDs in
more erroneous cases than before. One downside of this is that we now produce a spurious
"type annotation missing in pattern"
diagnostic in some cases. I'll take care of that in a follow-on patch.
Swift SVN r26224
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 introduces a new pattern, spelled "x?" which is sugar for
matching ".Some(x)". It also changes the parser slightly so that
_ (the discard expr) is parsed as a unary expr instead of as an
expr. This allows it to have postfix ? after it, which is important
in pattern contexts to support "case _?:".
Swift SVN r25907
This affects the MacTypes.h header in the Darwin module as well as the
CarbonCore and OSServices sub-frameworks of the CoreServices framework.
API hidden in this way can still be accessed through qualified lookup
in case it's really needed, but will not appear in the module interface
or in code completion.
This is a hack, and it would be nice to remove it if/when all of this API
is officially marked as deprecated. I did check with Nick for MacTypes.h
and Chris Linn from CoreServices that this was a reasonable action to take.
rdar://problem/16806148
Swift SVN r24424
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
When trying to implement deduplication of results, found and fixed an issue
with loose checks for generic overload checking.
rdar://17995317
Swift SVN r21276
