In r26737, Sema was changed to not wrap Self occurring in a protocol
extension in a DynamicSelf. The commit message was rather terse but
I believe this is because the metadata for Self is bound to the static
base type, not the runtime base type.
However, we still need to substitute Self in the return type for the
static base type in the case where the base is an existential,
otherwise we get an open existential type leaking out.
Also remove the default argument for replaceCovariantResultType(),
every call site passed in a value and it seems bad to omit it on
accident.
Fixes <rdar://problem/21433694>.
Swift SVN r29802
- Fix TypeCheckExpr.cpp to be more careful when propagating sugar from an
argument to the result of the function. We don't want to propagate parens,
because they show up in diagnostics later.
- Restructure FailureDiagnosis::diagnoseFailure() to strictly process the tree
in depth first order. Before it would only do this if contextual typing was
unavailable, leading to unpredictable inconsistencies between diagnostics.
- Always perform diagnoseContextualConversionError early, as part of the thing
that calls the visitor, instead of in each visit method. This may change in
the future, but is a simplification for now.
- Make the operator processing code handle the "candidate is an exact match"
case by emitting a diagnostic indicating that the result type of the operator
must not match expectations, instead of emitting the silly things like
"binary operator '&' cannot be applied to two Int operands" which is obviously
false.
These changes lead to minor improvements across the testsuite, and should make the
diagnostics more predictable for more complex real-world ones, but I haven't gone
through the radars yet.
Major missing pieces:
- CallExpr isn't using the same logic that the operators are.
- When you have a near match (only one argument mismatches) we should specifically
complain about that argument, instead of spewing an entire argument list.
- The noescape function attr diagnostic is being emitted twice now.
Swift SVN r29733
- If the closure being rewritten was nested inside of another
closure, we would rewrite the nested closure into a new closure
having cs.DC as its parent, rather than the DeclContext of the
outer closure as required.
- If the closure being rewritten had nested closures, the parent
DeclContext of the nested closures was set to the old closure,
not the new one.
Fix both problems by having coerceClosureExprToVoid() modify the
closure in place instead of creating a new closure.
Fixes <rdar://problem/20931915>.
Swift SVN r29563
Previously the placement of the OpenExistentialExpr was determined
entirely from the natural argument count of the function.
There was a hack to add any missing OpenExistentialExprs at the top
level, but this didn't work if the method had a Self return value
and there were intermediate expressions, eg, if someMethod has a
Self return, foo(anExistential.someMethod) would generate a
diagnostic about open existentials.
Change ExprRewriter to use a new existential placement algorithm
that instead walks up the expression stack to determine the outermost
function application of an existential base, and insert the
OpenExistentialExpr there.
Progress on <rdar://problem/21289579>.
Swift SVN r29448
getTypeOfIndependentSubExpression() might replace some values in the
given expression with OpaqueValueExprs, but if the type checker
decided to insert the corresponding OpenExistentialExpr at the top
level, the AST would now be in an inconsistent state, since
getTypeOfIndependentSubExpression() does not return a new expression
to the caller.
Ideally we would separate out type checking from expression rewriting
so that the latter is only performed when we know the expression
type checks, but that is a bigger project. For now, erase open
existentials after re-typechecking a sub-expression.
Fixes <rdar://problem/20598568>.
Swift SVN r29400
For a concrete type A and protocol type P, A <c P now implies
A.Type <c P.Type, not just A.Type < P.Type. This in turn means
that A.Type.Type <c P.Type.Type. To make the coercion work,
recursively peel off metatype layers when collecting conformances
and in a similar situation in IRGen.
Swift SVN r29377
This makes it clearer that expressions like "foo.myType.init()" are creating new objects, instead of invoking a weird-looking method. The last part of rdar://problem/21375845.
Swift SVN r29375
X.Protocol is an instance of Y.Type only if X conforms to Y. Since X
is a protocol, this is only true if X contains Y and Y is
self-conforming.
Note that this updates some tests that actually contained invalid code.
Fixes <rdar://problem/20915927>.
Swift SVN r29349
If 'x.init' appears as a member reference other than 'self.init' or 'super.init' within an initializer, treat it as a regular static member lookup for 'init' members. This allows a more explicit syntax for dynamic initializations; 'self.someMetatype()' looks too much like it's invoking a method. It also allows for partial applications of initializers using 'someMetatype.init' (though this needs some SILGen fixes, coming up next). While we're in the neighborhood, do some other correctness and QoI fixes:
- Only lookup initializers as members of metatypes, not instances, and add a fixit (instead of crashing) to insert '.dynamicType' if the initializer is found on an instance.
- Make it so that constructing a class-constrained archetype type correctly requires a 'required' or protocol initializer.
- Warn on unused initializer results. This seems to me like just the right thing to do, but is also a small guard against the fact that 'self.init' is now valid in a static method, but produces a newly-constructed value instead of delegating initialization (and evaluating to void).
Swift SVN r29344
Instead of forcing full application of '{super,self}.init' in the parser, and installing the RebindSelf semantic expr node early, make these constraints to Sema-time checks, and parse '<expr>.init' as a regular postfix production. This is a better separation of concerns, and also opens the door to supporting 'metatype.init()' in more general expression contexts (though that part still needs some follow-up sema work).
Swift SVN r29343
If P is a protocol, calling static methods or constructors
via values of type P.Protocol makes no sense, so let's prohibit
this.
Fixes <rdar://problem/21176676>.
Swift SVN r29338
Rename existentialConformsToSelf() to existentialTypeSupported(). This
predicate is the "protocol has no Self or associated type requirements"
check, which is a looser condition than self-conformance. This was being
tested to see if the user could refer to the protocol via an existential
type.
The new existentialConformsToSelf() now checks for protocol being @objc,
and for the absence of static methods. This is used as part of the
argument type matching logic in matchType() to determine if the
existential can be bound to a generic type parameter.
The latter condition is stricter, for two reasons:
1) We allow binding existentials to multiple type parameters all sharing
the same generic type parameter T, so we don't want the user to be
able to see any static methods on T.
2) There is an IRGen limitation whereby only existentials without witness
tables can be passed in this manner.
Using the above, the representsNonTrivialGenericParameter() function
has been renamed to canBindGenericParamToExistential(). It now allows
an existential type to be bound to a generic type parameter only under
the following circumstances:
A) If the generic type parameter has no conformances, the match is allowed.
B) If the generic type parameter has at least one conformance, then all
of the conformances on the generic type parameter must be
existentialConformsToSelf() (condition 1 above), and all conformances
on the existential must be @objc (condition 2 above).
Fixes <rdar://problem/18378390> and <rdar://problem/18683843>, and lays
the groundwork for fixing a few other related issues.
Swift SVN r29337
Special-casing these as MemberRefExprs created an asymmetry
where unbound archetype instance methods (<T : P> T.f) could
not be represented. Treating class and protocol methods
uniformly also eliminates a handful of special cases around
MemberRefExpr.
SILGen's RValue and call emission peepholes now have to know
about DeclRefExprs that point to protocol methods.
Finally, generalize the diagnostic for partially applied
mutating methods to any partially applied function with an
inout parameter, since this is not supported.
Fixes <rdar://problem/20564672>.
Swift SVN r29298
- Remove unused names.
- Define IDENTIFIER in terms of IDENTIFIER_WITH_NAME.
- Adjust each name to always match the corresponding value in case.
- Add an IDENTIFIER_ macro for the common case of defining an underscored name.
- Avoid creating names with double underscores, which are technically reserved
by the C++ standard.
There are two special cases I left in here for the identifiers '_code' and
'_domain'. I didn't want to call these simply 'Id_code' and 'Id_domain' for
fear someone would try to use them as 'code' and 'domain', so I made them into
'Id_code_' and 'Id_domain_' for now.
No intended functionality change.
Swift SVN r29291
If we end up trying to form a substitution where the replacement type
is an existential and there is a conformance to a non-@objc protocol
(i.e., a conformance where a witness table is required), complain in
Sema rather than crashing in IRGen. Fixes rdar://problem/21087341, but
the existential/generic interaction is still quite broken.
Swift SVN r29133
This results in a more correct diagnostic being printed for closures with
capture lists, rather than claiming that they aren't literal closures.
Swift SVN r29058
Our implementation of partial_apply and currying is robust enough to handle these cases now. Mutating methods are still problematic since capturing would violate 'inout' semantics. (Maybe we could support 'mutating' partial applications as @noescape closures, some day.)
Swift SVN r28992
This isn't as straightforward as it should be, since EnumElementDecls aren't AbstractFunctionDecls, but luckily there's only one trivial curry level with a thin metatype parameter.
Swift SVN r28991
Instead, provide the location of the { in a closure expr to the argument formation as
part of the datastructure already used to manage implicit closure arguments in the parser.
Swift SVN r28818
- 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
