And give a proper warning when you use 'try?' in a non-failable init.
And do the right thing when trying to SILGen 'try?' delegating to a
failable throwing init.
And make sure DI understands that this is, in fact, an initialization.
More rdar://problem/21692467
Swift SVN r31060
Fix construction and simplication of constructor member locators, so
that locators involving constructor members can be simplified during
diagnosis.
<rdar://problem/21427130> Swift can't discriminate on arity of function parameters
Swift SVN r30932
Instead of relying on the reference semantics of the base to make this decision, look at the getter and setter to see if either is mutating to decide whether the base of a property lookup should be inout. This should be the final fix for rdar://problem/21578832.
Swift SVN r30887
This came up with SourceKit fuzz testing on the stdlib. I don't have a
reduced testcase right now.
Progress on <rdar://problem/19554069>.
Swift SVN r30882
get the same wording, fixing <rdar://problem/21964599> Different diagnostics for the same issue
While I'm in the area, remove some dead code.
Swift SVN r30713
typeCheckExpression takes a convertType and a contextualType, but the only
client of contextualType is pattern binding initialization that wants to
provide a hint to the initializer, but the type may not be fully formed
(e.g. just Array instead of Array<Int>) so it can't provide a full
convertType to that type.
After trying various ways of eliminating the concept and failing, repaint it
instead: instead of typeCheckExpression taking *both* a convertType and a
contextualType (even though they are mutually exclusive), have it only take
a single convertType and add a bit to TypeCheckExprOptions to indicate whether
it is a hint or a strong conversion. This simplifies all the callers of
typeCheckExpression and makes further evolution simpler.
Swift SVN r30658
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
