we parsed, otherwise the type checker gets confused later. This fixes these
regressions:
Swift :: compiler_crashers_fixed/0725-swift-type-walk.swift
Swift :: compiler_crashers_fixed/0742-swift-metatypetype-get.swift
Swift :: compiler_crashers_fixed/1501-swift-diagnosticengine-flushactivediagnostic.swift
Swift :: compiler_crashers_fixed/1705-vtable.swift
Also, that patch fixed 0791-swift-type-walk.swift, so mark it as not crashing.
Swift SVN r28108
includes a number of QoI things to help people write the correct code. I will commit
the testcase for it as the next patch.
The bulk of this patch is moving the stdlib, testsuite and validation testsuite to
the new syntax. I moved a few uses of "as" patterns back to as? expressions in the
stdlib as well.
Swift SVN r27959
Fixes the crash in rdar://problem/20564378. In these cases, we end up
swallowing some diagnostics. That will be addressed in a subsequent
commit.
Swift SVN r27436
Consistently open all references into existentials into
opened-existential archetypes within the constraint solver. Then,
during constraint application, use OpenExistentialExprs to record in
the AST where an existential is opened into an archetype, then use
that archetype throughout the subexpression. This simplifies the
overall representation, since we don't end up with a mix of operations
on existentials and operations on archetypes; it's all archetypes,
which tend to have better support down the line in SILGen already.
Start simplifying the code in SILGen by taking away the existential
paths that are no longer needed. I suspect there are more
simplifications to be had here.
The rules for placing OpenExistentialExprs are still a bit ad hoc;
this will get cleaned up later so that we can centralize that
information. Indeed, the one regression in the compiler-crasher suite
is because we're not closing out an open existential along an error
path.
Swift SVN r27230
Per discussion on the list. From now on, when you fix a compiler_crashers
test case, move it to compiler_crashers_fixed so that we get no-asserts and
ASan coverage.
Swift SVN r27055
- Enhance PBD with a whereExpr/elseStmt field to hold this.
- Start parsing the pattern of let/var decls as a potentially refutable pattern. It becomes
a semantic error to use a refutable pattern without an 'else' (diagnostics not in place yet).
- Change validatePatternBindingDecl to use 'defer' instead of a goto to ensure cleanups on exit.
- Have it resolve the pattern in a PBD, rewriting it from expressions into pattern nodes when valid.
- Teach resolvePattern to handle TypedPatterns now that they can appear (wrapping) refutable patterns.
- Teach resolvePattern to handle refutable patterns in PBD's without initializers by emitting a diagnostic
instead of by barfing, fixing regressions on validation tests my previous patch caused, and fixing
two existing validation test crashers.
Sema, silgen, and more tests coming later.
Swift SVN r26706
We were ending up looking in the parent context, but it didn't matter
because the parser pre-resolved the names of generic parameters. We
shouldn't be relying on the parser to do that.
Note that this regresses four compiler crashes, because they end up
looking back into their own generic parameter lists in unhealthy
ways. I'm going to temporarily burn some karma because of what this
enables...
Swift SVN r26688
Remove the semantic restrictions that prohibited extensions of
protocol types, and start making some systematic changes so that
protocol extensions start to make sense:
- Replace a lot of occurrences of isa<ProtocolDecl> and
dyn_cast<ProtocolDecl> on DeclContexts to use the new
DeclContext::isProtocolOrProtocolExtensionContext(), where we want
that behavior to apply equally to protocols and protocol extensions.
- Eliminate ProtocolDecl::getSelf() in favor of
DeclContext::getProtocolSelf(), which produces the appropriate
generic type parameter for the 'Self' of a protocol or protocol
extension. Update all of the callers of ProtocolDecl::getSelf()
appropriately.
- Update extension validation to appropriately form generic
parameter lists for protocol extensions.
- Methods in protocol extensions always use the witnesscc calling
convention.
At this point, we can type check and SILGen very basic definitions of
protocol extensions with methods that can call protocol requirements,
generic free functions, and other methods within the same protocol
extension.
Regresses four compiler crashers but improves three compiler
crashers... we'll call that "progress"; the four regressions all hit
the same assertion in the constraint system that will likely be
addressed as protocol extensions starts working.
Swift SVN r26579
Having semantic checking in type validation introduces the potential for more recursion, triggering crashes. By moving this semantic restriction out to a later stage, we make it more robust. Fixes 6 compiler crashers, although it regressed one compiler crasher that hits a different known issue (assertions in addGenericParameters when we have multiple parameters at the same depth).
Swift SVN r26226
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
requires pushing the types out. The only interesting one is this diff:
- var (e,f,g:(),h) = MRV()
+ var (e,f,g,h) : (Int, Float, (), Double) = MRV()
... where the type annotation is required to silence the warning about "void type
may be unexpected". This seems perfectly reasonable to me.
Swift SVN r26161
This changes 'if let' conditions to take general refutable patterns, instead of
taking a irrefutable pattern and implicitly matching against an optional.
Where before you might have written:
if let x = foo() {
you now need to write:
if let x? = foo() {
The upshot of this is that you can write anything in an 'if let' that you can
write in a 'case let' in a switch statement, which is pretty general.
To aid with migration, this special cases certain really common patterns like
the above (and any other irrefutable cases, like "if let (a,b) = foo()", and
tells you where to insert the ?. It also special cases type annotations like
"if let x : AnyObject = " since they are no longer allowed.
For transitional purposes, I have intentionally downgraded the most common
diagnostic into a warning instead of an error. This means that you'll get:
t.swift:26:10: warning: condition requires a refutable pattern match; did you mean to match an optional?
if let a = f() {
^
?
I think this is important to stage in, because this is a pretty significant
source breaking change and not everyone internally may want to deal with it
at the same time. I filed 20166013 to remember to upgrade this to an error.
In addition to being a nice user feature, this is a nice cleanup of the guts
of the compiler, since it eliminates the "isConditional()" bit from
PatternBindingDecl, along with the special case logic in the compiler to handle
it (which variously added and removed Optional around these things).
Swift SVN r26150
a let/var pattern. Now any identifier in one of these is a variable binding,
not sometimes a value references (depending on contextual syntax).
This isn't expected to have a widespread effect on existing real world code:
- No impact on the stdlib.
- It does fix two validation crash tests, but possibly because the original issue is hidden by a different diagnostic path in the compiler.
- This needed two tests to be tweaked to undistribute "let".
On the positive side, this means that "case let x?:" now works properly, woo.
Swift SVN r26000
<rdar://problem/19919467> Interpreter/repl.swift regressed under ASan
<rdar://problem/19919459>
compiler_crashers/0214-swift-typebase-gettypeofmember.swift regressed
under ASan
Swift SVN r25483
When referring to a type declaration that is a member of some nominal
type, we were relying on substitution into the non-interface type,
which is silly. Use the interface type here.
Other than some type-printing differences, this should be NFC.
Slight regression in two compiler crashes that had been fixed in the
previous commit; I'll look into these shortly.
Swift SVN r25385
This lets us disambiguate the symbols for static and instance properties, and enables us to eventually leave the useless "self" type mangling out of method symbols. Fixes rdar://19012022 and dupes thereof, including crasher #1341.
Swift SVN r25111
