Provide compiler-synthesized implementations of ErrorType that use the type name as domain and a per-case integer as code. (TBD would be some mapping of the associated data to userInfo in Cocoa.)
Swift SVN r26780
For structs/enums, this was already the case. For classes, we simply
need to ensure that we always look at the extensions of protocols to
which the class conforms.
Swift SVN r26773
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
When synthesizing a designated initializer override, we now ensure that the synthesized
initializer has the same availability as the initializer it is overriding.
Swift SVN r26732
Implement simplistic partial ordering rules for members of protocol
extensions. Specifically:
- A member of a concrete type is more specialized than a member of a
protocol extension
- A member of a protocol extension of P1 is more specialized than a
member of a protocol extension of P2 if P1 inherits from P2
This achieves most of what rdar://problem/20335936 covers, but does
not yet handle ordering between constrained protocol extensions.
Swift SVN r26723
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
to find variables, enabling it to work with refutable patterns in
addition to nonrefutable ones. This allows eliminating some special
case code in the parser, NFC.
Swift SVN r26686
This tool takes the input of two versions of the same sdk and outputs
their diff to facilicate the auto-migration of sdk clients.
In this initial commit, we take the path of one sdk and generate
a tree describing its API content. Next, we will diff trees generated
from different versions of the sdk.
In addition, this commit also refactored out part of swift-sdk-analyzer
to the common utils shared with swift-sdk-digester.
Swift SVN r26656
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
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 (without associated types, IRGen crashes, etc.)
with methods that can call protocol requirements, generic free
functions, and other methods within the same protocol extension.
This is identical to r26579; the prior commit addressed the underlying
conformance substitution problem that caused rdar://problem/20320393
and subsequent reversion of r26579.
Swift SVN r26639
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
We can now use internal declarations safely and correctly in source files!
The remaining work is to make sure testable imports work reliably through
modules, which is important for debugging unit tests.
It's also possible this work will affect compile time, but for the most
part we don't have large quantities of internal declarations that are
being ignored, and some day we will strip them out of non-testable modules
altogether.
Part of rdar://problem/17732115
Swift SVN r26633
We do a silly little dance here of finding all of the members of
protocols and their extensions, then deleting the protocol members. In
the future, this is the place where we should handle the protocol
requirement -> witness mapping, including handling derived
conformances.
Basic protocol extensions seem to be working now:
extension SequenceType {
var myCount: Int {
var result = 0
for x in self {
++result
}
return result
}
}
println(["a", "b", "c", "d"].myCount) // 4, duh
Swift SVN r26617
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
There must be a better way ... to get us moving forward i am committing this
until somebody tells me how to do this right (tm).
rdar://20265255
Swift SVN r26455
When we print the name of a protocol conformance, we normally use the generic parameters as written. However, since some requirements may be inferred (particularly by an extension of a generic type), it's better for the SIL printer to use the generic signature, which is fully expanded and will also be correct, e.g., when working with a deserialized conformance.
Swift SVN r26437
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
