Enable checking for uses of potentially unavailable APIs. There is
a frontend option to disable it: -disable-availability-checking.
This commit updates the SDK overlays with @availability() annotations for the
declarations where the overlay refers to potentially unavailable APIs. It also changes
several tests that refer to potentially unavailable APIs to use either #available()
or @availability annotations.
Swift SVN r27272
The only caveat is that:
1. We do not properly recognize when we have a let binding and we
perform a guaranteed dynamic call. In such a case, we add an extra
retain, release pair around the call. In order to get that case I will
need to refactor some code in Callee. I want to make this change, but
not at the expense of getting the rest of this work in.
2. Some of the protocol witness thunks generated have unnecessary
retains or releases in a similar manner.
But this is a good first step.
I am going to send a large follow up email with all of the relevant results, so
I can let the bots chew on this a little bit.
rdar://19933044
Swift SVN r27241
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
Retire the old components now that the new ones have passed API review.
<rdar://20406937> covers the migration fallout of this change.
Swift SVN r27092
Retire the old components now that the new ones have passed API review.
<rdar://20406937> covers the migration fallout of this change.
Swift SVN r27081
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
Simplify the observation evaluation in the ErrorType race test by using evaluateObservationsAllEqual, and run the test for real. Apparently round-trip NSString and NSDictionary bridging doesn't produce a stable object, so use valueForKey as a hack to sidestep bridging so we can verify that the identities of the bridged domain and code aren't racy.
Swift SVN r27003
Atomically initialize and load the NSError bridging fields within an ErrorType box so that we do the right thing when two threads concurrently coerce the box to NSError.
Swift SVN r26996
Retire the old components now that the new ones have passed API review.
<rdar://20406937> covers the migration fallout of this change.
Swift SVN r26904
- 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
