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
This adds generic parameters and generic signatures to extension
declarations. The actual generic parameters just mirror what is
available on the extended type; however, it is filled in via extension
validation, which is handled lazily.
This is a NFC step toward decoupling the archetypes of extensions from
the archetypes of the extended types <rdar://problem/16974298>.
Swift SVN r20675
This always wrapped a single GenericTypeParamDecl *, and provided no benefit
over just using the decl directly.
No (intended) functionality change.
Swift SVN r19628
This applies to both qualified and unqualified lookups, and is controlled
by the -enable-access-control and -disable-access-control flags. I've
included both so that -disable-access-control can be put into specific tests
that will eventually need to bypass access control (e.g. stdlib unit tests).
The default is still -disable-access-control.
Swift SVN r19146
conformances
rdar://16539292
This is a hack in visible decl lookup. The general solution that would also
improve type checker errors would be to make the type checker keep these broken
conformances and syntethize missing declarations to make downstream code type
check. For that, see:
<rdar://problem/16723339> [QoI] Type checker should not be dropping protocol
conformances explicitly spelled in the source
Swift SVN r16818
Introduce CtorInitializerKind to describe the kind of an enum, rather
than a bool, to make way for more initializer kinds in the future.
Swift SVN r16525
