and refutable pattern bindings without an initializer.
- Enhance ASTDumper to dump where/else clauses on PBDs.
- Merge if/let conditional PBD logic into the mainline logic now that they are all
potentially conditional (more simplifications coming for this)
add tests for the fixits, which exercise the earlier SourceRange enhancments, e.g.:
x.swift:3:5: error: refutable pattern match can fail; add an else {} to handle this condition
let o? = a
^~
else {}
Swift SVN r26751
Add an isRefutable() predicate to a PBD overall, which is true
iff the PBD has any refutable patterns in it or has a where clause.
NFC, not used yet.
Swift SVN r26708
- 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
Start parsing a "trailing" where clause for extension declarations, which follows the extended type name and (optional) inheritance clause. Such a where clause is only currently permitted for protocol extensions right now.
When used on a protocol extension, it allows one to create a more-constrained protocol extension, e.g.,
extension CollectionType where Self.Generator.Element : Equatable { ... }
which appears to be working, at least in the obvious cases I've tried.
More cleanup, tests, and penance for the previous commit's "--crash" introductions still to come.
Swift SVN r26689
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
Rename 'assignment' attribute of infix operators to 'mutating'. Add
'has_assignment' attribute, which results in an implicit declaration of
the assignment version of the same operator. Parse "func =foo"
declaration and "foo.=bar" expression. Validate some basic properties of
in-place methods.
Not yet implemented: automatic generation of wrapper for =foo() if foo()
is implemented, or vice versa; likewise for operators.
Swift SVN r26508
SIL seems to be doing the right thing here already, which is great!
Part of rdar://problem/17732115. We'll be able to really see this working
with the next change: allowing references to testable things when using
"@testable import".
Swift SVN r26473
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
Getting the protocols of an arbitrary type doesn't make sense, so start phasing this out by introducing specialized entry points that do make sense:
- get the inherited protocols of a ProtocolDecl
- get the conforming protocols for an associated type or generic
type parameter
- (already present) ask for the protocols to which a nominal type conforms
Swift SVN r26411
The commit fixes availability Fix-Its on enum elements to suggest a new availability
attribute on the enum case (which is where attributes live in concrete syntax) rather than
on the enum element (which is where they are attached in the abstract syntax tree).
Swift SVN r26401
We explicitly whitelist these "stdlib private" decls in interface
generation, because they may contain methods that users are required to
implement. But in code-completion, there's no good reason to show them.
We still show completions for the methods themselves if you complete on
a public protocol that inherits from the private protocol. So,
<complete> => doesn't show _CollectionType
let a: CollectionType = ...
a.<complete> => *does* show startIndex, which comes from _CollectionType
rdar://problem/20086106
Swift SVN r26355
We now access the conformances of a nominal type through the
conformance lookup table, so there is no reason to continue storing
conformances directly on the nominal type declaration, which was
error-prone regardless. This mirrors the change to ExtensionDecl from
my previous commit.
Swift SVN r26354
Stop storing a conformances array on ExtensionDecls. Instead, always use the conformance lookup table to retrieve conformances (which is lazy and supports multi-file, among other benefits).
As part of this, space-optimize ExtensionDecl's handling of conformance loaders. When one registers a conformance loader, it goes into a DenseMap on ASTContext and gets erased once we've loaded that data, so we get two words worth of space back in each ExtensionDecl.
Swift SVN r26353
Replace the loop over all known protocols with a query into the
actual conformance lookup table, which more properly deals with
out-of-order conformance queries, inheritance of protocol
conformances, and conformance queries in multi-file situtations.
The SILGen test change is because we're no longer emitting redundant
conformances, while the slight diagnostic regression in
circular-inheritance cases is because we handle circular inheritance
very poorly throughout the compiler.
While not the end, this is a major step toward finishing
rdar://problem/18448811.
Swift SVN r26299
Previously, we would require the type checker to be able to build a
conformance, which meant we would actually have to lie in the AST
about having a conformance (or crash; we did the form). Now, we can
form the conformance in the AST and it will be checked in the type
checker when needed. The intent here is to push conformance creation
into the conformance lookup table.
To get here, we had to stop relying on the broken, awful,
ASTContext-wide conformance "cache". A proper cache can come back once
the model is sorted out.
Swift SVN r26250
Instead of relying on Sema to set the existential-conforms-to-self bit, compute it lazily in the AST. This is far cleaner and more dependable than the previous solution.
Swift SVN r26225
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
- Rename getParentPattern() -> getParentPatternBinding(), since
it returns the pattern binding, not the pattern.
- Introduce new getParentPattern()/getParentInitializer() methods,
covering the most common uses of getParentPatternBinding().
NFC.
Swift SVN r26175
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
It causes some fails in compiler_crashers:
Swift :: compiler_crashers/0986-swift-unboundgenerictype-get.swift
Swift :: compiler_crashers/1103-swift-unboundgenerictype-get.swift
Swift :: compiler_crashers/1223-swift-lexer-leximpl.swift
Swift :: compiler_crashers/1276-swift-metatypetype-get.swift
Swift :: compiler_crashers/1287-swift-printingdiagnosticconsumer-handlediagnostic.swift
Swift SVN r26136
This is effectively NFC, but we had two implementations of "figure out
the protocols that this type should implicitly conform to". The one in
the conformance table is what will matter going forward.
Swift SVN r26115
The conformance lookup table should ask for registration, it should
*know* what the conformances will be based on the form of the AST. NFC
Swift SVN r26114
This reverts commit r26082.
We cannot assume that NSArray count or objectAtIndex don't not have side effects
that are observed from Swift. We have to assume they could change an object that
is visible from Swift and therefore they are may-release.
Swift SVN r26099
This enables it to move retain about critical objective c method calls such as
objectAtIndex and count used by Array.
Improves DeltaBlue by 35% at -O.
radar://20147568
Swift SVN r26082
(Note that this registry isn't fully enabled yet; it's built so that
we can test it, but has not yet taken over the primary task of
managing conformances from the existing system).
The conformance registry tracks all of the protocols to which a
particular nominal type conforms, including those for which
conformance was explicitly specified, implied by other explicit
conformances, inherited from a superclass, or synthesized by the
implementation.
The conformance registry is a lazily-built data structure designed for
multi-file support (which has been a problematic area for protocol
conformances). It allows one to query for the conformances of a type
to a particular protocol, enumerate all protocols to which a type
conforms, and enumerate all of the conformances that are associated
with a particular declaration context (important to eliminate
duplicated witness tables).
The conformance registry diagnoses conflicts and ambiguities among
different conformances of the same type to the same protocol. There
are three common cases where we'll see a diagnostic:
1) Redundant explicit conformance of a type to a protocol:
protocol P { }
struct X : P { }
extension X : P { } // error: redundant explicit conformance
2) Explicit conformance to a protocol that collides with an inherited
conformance:
protocol P { }
class Super : P { }
class Sub : Super, P { } // error: redundant explicit conformance
3) Ambiguous placement of an implied conformance:
protocol P1 { }
protocol P2 : P1 { }
protocol P3 : P1 { }
struct Y { }
extension Y : P2 { }
extension Y : P3 { } // error: ambiguous implied conformance to 'P1'
This happens when two different explicit conformances (here, P2 and
P3) placed on different declarations (e.g., two extensions, or the
original definition and other extension) both imply the same
conformance (P1), and neither of the explicit conformances imply
each other. We require the user to explicitly specify the ambiguous
conformance to break the ambiguity and associate the witness table
with a specific context.
Swift SVN r26067
when computing the list. This simplifies getLocalCaptures to *just* filter out
global captures, and paves the way for other enhancements. NFC.
Swift SVN r25739
...rather than just assuming any initializer without a body that makes it
to SILGen is a memberwise initializer.
In the long term we want SILGen to stop handling these initializers, at
which point we can see if it makes sense to remove this body kind.
No intended functionality change.
Swift SVN r25723
There are a handful of Objective-C initializers with names like
"initForMemory" that take no parameters. The Clang importer has long
been importing them with a single parameter of type (), e.g.,
init(forMemory: ())
At some point, our @objc checking got stricter and started rejecting
parameters of type (), making it impossible to define such an
initializer in Swift. Codify this case in @objc checking, fixing
rdar://problem/19973250.
Swift SVN r25611
Always perform override checking based on the Swift type
signatures, rather than alternately relying on the Objective-C
selectors. This ensures that we get consistent override behavior for
@objc vs. non-@objc declarations throughout, and we separately make
sure that the Objective-C names line up.
This also allows us to inherit @objc'ness correctly (which didn't
quite work before), including inferring the Objective-C selector/name
(the actual subject of rdar://problem/18998564).
Fixes rdar://problem/18998564.
Swift SVN r25392
