On platforms that are not explicitly mentioned in the #os() guard, this new '*'
availability check generates a version comparison against the minimum deployment target.
This construct, based on feedback from API review, is designed to ease porting
to new platforms. Because new platforms typically branch from
existing platforms, the wildcard allows an API availability check to do the "right"
thing (executing the guarded branch accessing newer APIs) on the new platform without
requiring a modification to every availability guard in the program.
So, if the programmer writes:
if #os(OSX >= 10.10, *) {
. . .
}
and then ports the code to iOS, the body will execute.
We still do compile-time availability checking with '*', so the compiler will
emit errors for references to potentially unavailable symbols in the body when compiled
for iOS.
We require a '*' clause on all #os() guards to force developers to
"future proof" their availability checks against the introduction of new a platform.
Swift SVN r26988
We only require one of the patterns in a multi-pattern PBD to be conditional
as part of the swift 1 migation. Relax the requirements to allow unconditional
bindings next to conditional ones. This required moving some logic from the parser
to sema time.
Swift SVN r26987
To use members of protocol extensions on existential types, we
introduce an OpenExistentialExpr expression to open up the existential
type (into a local archetype) and perform the operations on that local
archetype.
Unlike with uses of initializers or dynamic-Self-producing
methods of protocols, which produce similar ASTs, we have the type
checker perform the "open" operation and then track it through
constraint application. This scheme is better (because it's more
direct), but it's still using a simplistic approach to deciding where
the actual OpenExistentialExpr goes that needs improvement.
Swift SVN r26964
- Implement SILGen for conditional multi-pattern PBD's.
- Have the type checker check where clauses on PBDs.
- Change the AST to represent complex if/let PBD's with
composed PBDs instead of breaking them down. For example,
represent:
if let x? = foo(), y? = bar() where x == y {
as a single PBD in a StmtCondition instead of representing
it as three entries in the condition.
The later change is good for AST/source fidelity as well as providing
a cheap way to exercise all the logic I'm building.
Swift SVN r26959
We do this by banning single-element tuple patterns with a label (in most cases).
We now produce:
x.swift:2:8: error: label is not allowed on single element tuple pattern
let (responseObject: Int?) = f()
^
x.swift:2:7: note: remove the parentheses to make this a type annotation
let (responseObject: Int?) = f()
^ ~
x.swift:2:8: note: remove the label to make this a tuple pattern
let (responseObject: Int?) = f()
^~~~~~~~~~~~~~~
Swift SVN r26898
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
Now that tuple pattern labels are squared away, we can detect mismatches and produce
diagnostics that point exactly to the problematic label. Right now we require the
tuple labels to match up (or be absent) from the pattern, and produce this diagnostic
if not:
x.swift:7:20: error: tuple pattern element label 'xxx' must be 'one'
case let .Case(xxx: _, two: x):
^
In the future we could support reshuffling if it someone cares enough to support it.
The important thing for now is to fix the miscompilation.
Swift SVN r26865
exposed keyword arguments into the TuplePatterns labels.
Switch tuple conversion to use tuplepattern labels instead of parameter labels.
Swift SVN r26861
We're not going to require the type parameters to be redeclared on
extensions of generic types, so take away the staging option and
diagnostic.
Swift SVN r26854
This pushes tuple pattern labels forward:
- Actually record them in TuplePatternElt.
- Remove the tuple shuffle ban that prevents some cases
(e.g. the one in the radar) of a tuple with labels being shuffled
onto a tuple without labels.
- Remove dead code enabled by removing the restriction.
Swift SVN r26852
to represent them, and just dropped them on the ground. Now we parse them,
persist them in the AST, and "resolve" them from the expr grammar, but still
drop them on the ground. This is progress towards fixing: rdar://20135489
Swift SVN r26828
Have TypeChecker's constructor register itself as the lazy resolver,
and its destructor unregister itself. This introduces the
completely-sensible restriction that there can only be one type
checker active for an ASTContext at a time, which is the case already.
Use ASTContext's lazy resolver in a single place that's been causing
trouble (rdar://problem/20363958, rdar://problem/19773096), where
deserializing a protocol conformance can cause us to pass a null lazy
resolver into the protocol conformance table, which doesn't handle it
well. This commit fixes those issues, which I'm unable to reduce down
to a sane-enough test case to commit.
This commit implies a ton of cleanup work to eliminate LazyResolver
parameters from *everywhere*, deriving them from the ASTContext in the
few places they're needed as well. It's a good direction, but that
cleanup can be evolutionary.
Swift SVN r26824
early instead of leaving them to TypeCheckExpr to find in an arbitrary "late"
place in type checking. This gives us better (more localized) diagnostics and
reduces downstream errors when a pattern is malformed. This is the
foundation to produce more specific errors than "invalid pattern"
Swift SVN r26802
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
Members of protocol extensions cannot be @objc because there is no
sensible class to which we could attach an Objective-C method. This
was already diagnosed as an error (because protocol extensions are
generic contexts), so specialize the diagnostic slightly.
Swift SVN r26768
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
Compare the generic signatures so that we get appropriate partial
ordering among constrained extensions, extensions of inherited
protocols, etc. Finishes rdar://problem/20335936.
Swift SVN r26726
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
- 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 now disregard deprecation warnings if the reference to a deprecated symbol is lexically
contained in a declaration that is itself deprecated on all deployment targets.
Swift SVN r26693
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
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
Update AvailabilityFixitParentFinder (and rename it) to find the innermost node in the AST
that both contains a given SourceRange and matches a given predicate. I will use this more
general facility in a later commit. NFC.
Swift SVN r26683
Type aliases of unbound generic type are ill-formed, so LLDB was
running into an assertion that the compiler would normally get
into that an extension of a generic type has already had generic
parameters provided (by bindExtensionDecl). Longer term, LLDB should
find another appropriate that doesn't rely on ill-formed ASTs. For
now, try to work around the assertion by cloning the generic parameter
list when we validate the extension.
Hopefully fixes rdar://problem/20335682, but this is untestable in the
compiler itself.
Swift SVN r26673
It’s real intent is to check only the generic signature of the DeclContext provided to name lookup, then enclosing contexts. Use it for functions and initializers as well, so we have uniform lookup behavior for entities that can have generic parameters.
A follow-up commit contains some minor, semi-related tweaks along with a pile of updates to the compiler crash testsuite.
Swift SVN r26654
The declaration whose inheritance clause is being checked has enough
information to figure this out. Callers will just screw it up anyway.
Swift SVN r26653
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
