- Enable 'catch is NSError' and 'catch let e as NSError {' patterns to
a) work, and b) be considered to be exhaustive catches. This enables
people to catch an error and *use* it as an NSError directly, instead
of having to do boiler-platey cases. This is particularly important
for the migrator.
- Do not warn about non-noop coersion casts (like "_ as NSError" when
matching an ErrorType), since they provide useful type adjustment to
the subpattern. Still warn on noop ones.
- Simplify CatchStmt::isSyntacticallyExhaustive to use
Pattern::isRefutablePattern. Add a FIXME, because the parser is guiding
closure "throws" inference before the pattern is type checked, which means
that it is incorrect (but only in subtle cases).
- When diagnosing pointless 'as' patterns like:
switch 4 {
case _ as Int: break
say "'as' test is always true" instead of "'is' test is always true".
Swift SVN r28774
Fix a nullptr dereference when looking for a base expression
in a member access. Remove use of Optional<T*>, it wasn't providing
any value versus nullptr checking.
Swift SVN r28648
When in an initializer, we allow setting into immutable properties
provided that the type of base in `base.member` matches that of that
initializer's containing type. This was an approximation for allowing
full access into `self` during initialization but this doesn't work when
passing in a different struct of the same type because that struct
should be still be immutable.
Check whether the base of the member access is the implicit self
parameter of the initializer before allowing mutation.
rdar://problem/19814302
Swift SVN r28634
instead of being an expression.
To the user, this has a couple of behavior changes, stemming from its non-expression-likeness.
- #available cannot be parenthesized anymore
- #available is in its own clause, not used in a 'where' clause of if/let.
Also, the implementation in the compiler is simpler and fits the model better. This
fixes:
<rdar://problem/20904820> Following a "let" condition with #available is incorrectly rejected
Swift SVN r28521
... and since they can only use required initializers (or those found
in a protocol), one can use them when constructing metatypes. Fixes
rdar://problem/20739719.
Swift SVN r28364
can make a more precise assertion that all default arguments have the
same owner.
<rdar://problem/20749423> Compiler crashed while building simple subclass code
Swift SVN r28251
optional evaluation context that produced the optional.
<rdar://problem/20377684> Oscillating fixit for optional chain calling method that returns non-optional
Swift SVN r28212
since the type might not match the return type of the function exactly
in that case (CSGen only emits a conversion constraint).
<rdar://problem/20087517> Crash when using .staticShorthand syntax with NSColor/UIColor factories
Swift SVN r28200
When semantic analysis forms a reference to a conformance that will
persist in the AST (it is "used" in the C++ odr-used sense), complete
that conformance before type checking terminates. This ensures that
the SIL optimizers have complete conformances to work with for, e.g.,
generic specialization. Fixes rdar://problem/20735544.
Swift SVN r27896
This fixes <rdar://problem/20494437> SILGen crash handling default arguments
again, and includes a fix for MiscDiagnostics to look through the generated
TupleShuffleExprs in @noescape processing (which tripped up XCTest).
This fixes <rdar://problem/16860940> QoI: Strict keyword arguments loses type sugar in calls
where we'd lose some type sugar.
This fixes sanity in the ASTs: ScalarToTupleExpr now always has consistent
types between its argument and result, so we can turn on AST Verification of it.
Swift SVN r27827
This was an ugly situation where we'd create an invalid ScalarToTuple in
a situation with default arguments, because CSApply didn't realize that the
default argument causes formation of a specific tuple kind with a single element.
There is more damage in this area, other work coming.
Swift SVN r27811
DI makes the assumption that the type of self in an initializer is always
derived from a nominal type. Now that you can put an initializer body on a
protocol, this isn't true anymore, so teach it about this.
Swift SVN r27714
Replace the 'ignoreMissing' boolean flag with a new option set type,
SubstOptions, which is easier to extend. It is not an OptionSet<>
because a follow-on commit will introduce a non-trivial option that
will require more storage.
Also eliminate the LazyResolver parameter, which is no longer
needed. Eliminate the silly TypeChecker::substType(), whose only
purpose was to provide the resolver.
Swift SVN r27656
This eliminates nonsensical recursion when working with protocol
conformances, and makes their checking more lazy. Start to improve
name lookup to deal with protocol witnesses more lazily, generalizing
the solution we had to all protocol conformances and making it more
directed. We're not done here, as the FIXMEs in the code completion
test imply: this replace-the-requirement-with-the-witness behavior
needs to be sunk down into the AST level so it also applies to
unqualified lookup, visible-decl lookup, etc.
Swift SVN r27639
We need to use the constrants from the extension, otherwise we might
pass in the wrong witness method table at the call site, among other
problems.
Fixes rdar://problem/20532214.
Swift SVN r27585
Add syntax "[#Color(...)#]" for object literals, to be used by
Playgrounds for inline color wells etc. The arguments are forwarded to
the relevant constructor (although we will probably change this soon,
since (colorLiteralRed:... blue:... green:... alpha) is kind of
verbose). Add _ColorLiteralConvertible and _ImageLiteralConvertible
protocols, and link them to the new expressions in the type checker.
CSApply replaces the object literal expressions with a call to the
appropriate protocol witness.
Swift SVN r27479
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
The post-type-checking error that was here is arguably better QoI, but it is causing ambiguities that break the non-ObjC-compatible build in the stdlib. We shouldn't even attempt these conversions if there's no runtime support to back them up.
Swift SVN r27407
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
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
We may want to use optimized ErrorType representations that don't naturally "become" NSErrors, such as tagged-pointer representations of small error enums, or a tagged function pointer to a deferred error type constructor. Rename the runtime function to something a bit more descriptive of its real purpose, not its implementation.
Swift SVN r27209
Previously, we were only opening the existentials as part of
constraint application, which involved some ugly, redundant code. This
should be NFC because it's just moving the existential opening
operation earlier, but it's a step toward opening up all existential
references.
Swift SVN r27190
Remove some unnecessary boilerplate when working with ExprRewriter and
eliminate some closeExistential() call sites that are no longer
useful. NFC.
Swift SVN r27107
Place OpenExistentialExprs for references to lvalue subscripts or properties
(in protocol extensions) via existentials just outside of the member
or subscript reference, rather than far outside the expression. This
gives us a tighter bound on the open-existential expressions without
introducing the post-pass I was threatening.
OpenExistentialExprs just outside of lvalue member/subscript are
themselves lvalues. Resurrect John's OpenOpaqueExistentialComponent to
handle the opening of a (materialized) existential lvalues as an
lvalue path component. This has the nice effect of codifying the
formal access rules for opened existentials as well as handling inout
on opened existentials appropriately.
Big thanks to John for talking through the model with me and leaving
dead code around for me to use.
Swift SVN r27105
If a conformance to _BridgedToObjectiveC is statically known, generate a more efficient code by using the newly introduced library functions for bridging casts.
This covers the cases arising from the source code, but does not cover any casts resulting from SIL optimizations. Those will be covered by the subsequent commit.
This change is to stay in CSApply for now. But the plan is to make the bridged casts optimization a guaranteed optimization. Once it is done, there is no need to lower the bridged casts in a special way inside Sema, because they all can be handled by the optimizer in a uniform way. This would apply to bridging of Error types too.
Swift SVN r27101
These aren't really orthogonal concerns--you'll never have a @thick @cc(objc_method), or an @objc_block @cc(witness_method)--and we have gross decision trees all over the codebase that try to hopscotch between the subset of combinations that make sense. Stop the madness by eliminating AbstractCC and folding its states into SILFunctionTypeRepresentation. This cleans up a ton of code across the compiler.
I couldn't quite eliminate AbstractCC's information from AST function types, since SIL type lowering transiently created AnyFunctionTypes with AbstractCCs set, even though these never occur at the source level. To accommodate type lowering, allow AnyFunctionType::ExtInfo to carry a SILFunctionTypeRepresentation, and arrange for the overlapping representations to share raw values.
In order to avoid disturbing test output, AST and SILFunctionTypes are still printed and parsed using the existing @thin/@thick/@objc_block and @cc() attributes, which is kind of gross, but lets me stage in the real source-breaking change separately.
Swift SVN r27095
To properly deal with mutating methods on protocol extensions accessed through an existential (such as a property or subscript setter), open the existential as an lvalue so that its value can be mutated.
As part of this, make sure we form any OpenExistentialExprs at the top level of the expression if we didn't manage to build them sooner. This is a fairly ad hoc approach that I am not happy with (these could probably be placed better with a post-pass), but the cost of opening too early is fairly minimal.
Swift SVN r27068
