directly into the diagnostics subsystem. This ensures a more consistent
treatment of type printing (e.g. catches a case where a diagnostic didn't
single quote the type) and gives these diagnostics access to "aka".
Swift SVN r30609
- Have DiagnosticEngine produce "aka" annotations for sugared types.
- Fix the "optional type '@lvalue C?' cannot be used as a boolean; test for '!= nil' instead"
diagnostic to stop printing @lvalue noise.
This addresses:
<rdar://problem/19036351> QoI: Print minimally-desugared 'aka' types like Clang does
Swift SVN r30587
Requiring a variadic parameter to come at the end of the parameter
list is an old restriction that makes no sense nowadays, and which we
had all thought we had already lifted. It made variadic parameters
unusable with trailing closures or defaulted arguments, and made our
new print() design unimplementable.
Remove this restriction, replacing it with a less onerous and slightly
less silly restriction that we not have more than one variadic
parameter in a given parameter clause. Fixes rdar://problem/20127197.
Swift SVN r30542
CSApply). The code is somewhat simpler there, more correct (fixing the FIXME in the
testcase) and doesn't run afoul of CSDiags trying to type check partial AST
subexpressions.
Swift SVN r30425
which allows solving of a constraint system to succeed without emitting
errors in the face of ambiguous solutions. This is important for CSDiag
because it is in the business of trying to solve subexpressions of a global
expression - and it wants to know the difference between a subexpression
that is inherently impossible to solve, vs one that is simply ambiguous
because its context has been removed.
Use this in CSDiag's typeCheckChildIndependently() to provide it an
extra flag that enables this behavior. This is currently unused, so NFC
with this patch.
Swift SVN r30402
To support this, make 'try' and 'try!' no longer IdentityExprs
and give them a common base class to simplify the sorts of
analyses and transformations that do want to treat them
as identity-like.
Note that getSPE() still looks through normal 'try', since
the overwhelming proportion of clients will consider it
semantically equivalent to the undecorated expression.
Change getValueProvidingExpr() to look through try!, since
it's allowed to return something with slightly different
semantics, and use it in the unused-result diagnostic.
Fixes a large number of bugs, mostly uncaught, with SILGen
peepholes that use getSPE() and therefore were accidentally
looking through try!. <rdar://21515402>
Swift SVN r30224
Adjust our placement of RebindSelfInConstructorExpr to fall outside of
a force-value expression (!), allowing, e.g.,
self.init(somethingThatCanFail: x)!
and
super.init(somehtingThatCanFail: x)!
Start suggesting '!' when chaining/delegating to a failable
initializer from a non-failable one, in addition to suggesting that
the enclosing initializer become failable.
Note that DI cannot handle this yet, so this is only the Sema part of
rdar://problem/18497407.
Swift SVN r30219
avoid emitting this diagnostics. They are always irritating to it because they
are duplicative with whatever the actual type constraint problem is. It also
interferes with there recursive structure of the problem.
Disabling them also allows us to shorten the black list of expr nodes that cannot
be handled in typeCheckIndependentSubExpression.
Swift SVN r30122
and getTypeOfExpressionWithoutApplying and change typeCheckExpression
to take it as a single-entry OptionSet, in prep for getting other
options. NFC.
Swift SVN r30121
... by reimplementing the DiscardAssignmentExpr checker in MiscDiagnostics
instead of being in CSApply (which gets run on partial expression ASTs).
Also, when type checking and salvaging an expression fails, do not generate
structural diagnostics in addition to the type checker diagnostics, they are
just noise.
Swift SVN r29937
- Remove a weird special case for literals from TypeChecker::typeCheckCondition.
- Enhance FailureDiagnosis::getTypeOfIndependentSubExpression to know about situations
where recursive type checks fail (in some nested situation) but still produce a type
for the top level of the expr tree.
- Remove dead code from CSApply now that you can't branch on Builtin.Int1.
The first & second combine to slightly improve one case I've been looking at in
test/expr/expressions.swift.
Swift SVN r29860
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
