Under -enable-infer-default-arguments, the Clang importer infers some
default arguments for imported declarations. Rather than jumping
through awful hoops to make sure that we create default argument
generators (which will likely imply eager type checking), simply
handle these cases as callee-side expansions.
This makes -enable-infer-default-arguments usable, fixing
rdar://problem/24049927.
This reverts commit 420bedaae1 because it
appears to have unintentionally made some previously accepted code
involving casts of variadic parameters to closures no longer compile.
that it is specific to ClosureExprs. Also, consolidate some logic
in CSDiags into the now shared coerceParameterListToType, which
makes a bit more sense and simplifies things a lot. NFC.
There are still unanswered questions. It isn't clear to me why
we support API names on closures, when we don't implement proper
semantic analysis for them. This seems like an accidentally supported
feature that should be removed.
Parameters (to methods, initializers, accessors, subscripts, etc) have always been represented
as Pattern's (of a particular sort), stemming from an early design direction that was abandoned.
Being built on top of patterns leads to patterns being overly complicated (e.g. tuple patterns
have to have varargs and default parameters) and make working on parameter lists complicated
and error prone. This might have been ok in 2015, but there is no way we can live like this in
2016.
Instead of using Patterns, carve out a new ParameterList and Parameter type to represent all the
parameter specific stuff. This simplifies many things and allows a lot of simplifications.
Unfortunately, I wasn't able to do this very incrementally, so this is a huge patch. The good
news is that it erases a ton of code, and the technical debt that went with it. Ignoring test
suite changes, we have:
77 files changed, 2359 insertions(+), 3221 deletions(-)
This patch also makes a bunch of wierd things dead, but I'll sweep those out in follow-on
patches.
Fixes <rdar://problem/22846558> No code completions in Foo( when Foo has error type
Fixes <rdar://problem/24026538> Slight regression in generated header, which I filed to go with 3a23d75.
Fixes an overloading bug involving default arguments and curried functions (see the diff to
Constraints/diagnostics.swift, which we now correctly accept).
Fixes cases where problems with parameters would get emitted multiple times, e.g. in the
test/Parse/subscripting.swift testcase.
The source range for ParamDecl now includes its type, which permutes some of the IDE / SourceModel tests
(for the better, I think).
Eliminates the bogus "type annotation missing in pattern" error message when a type isn't
specified for a parameter (see test/decl/func/functions.swift).
This now consistently parenthesizes argument lists in function types, which leads to many diffs in the
SILGen tests among others.
This does break the "sibling indentation" test in SourceKit/CodeFormat/indent-sibling.swift, and
I haven't been able to figure it out. Given that this is experimental functionality anyway,
I'm just XFAILing the test for now. i'll look at it separately from this mongo diff.
Previously, methods on DeclContext for getting generic parameters
and signatures did not walk up from type contexts to function
contexts, or function contexts to function contexts.
Presumably this is because SIL doesn't completely support nested
generics yet, instead only handling these two special cases:
- non-generic local function inside generic function
- generic method inside generic type
For local functions nested inside generic functions, SIL expects
the closure to not have an interface type or generic signature,
even if the contextual type signature contains archetypes.
This should probably be revisited some day.
Recall that these cases are explicitly rejected by Sema diagnostics
because they lack SIL support:
- generic function inside generic function
- generic type inside generic function
After the previous patches in this series, it becomes possible to
construct types that are the same as before for the supported uses of
nested generics, while introducing a more self-consistent conceptual
model for the unsupported cases.
Some new tests show we generate diagnotics in various cases that
used to crash.
The conceptual model might still not be completely right, and of
course SIL, IRGen and runtime support is still missing.
This time, the issue is that TypeNullifier skips bodies of
multi-statement closures. However, ExprRewriter will type
happily pass them on to typeCheckClosureBody(). This could
trigger assertions. Fix this by skipping type checking of
multi-statement closures when diagnosing.
There seems to be a minor QoI regression in some test cases
that already looked pretty dodgy and/or had FIXMEs. However
I think its worth fixing a crash.
mode (take 2)
Allow untyped placeholder to take arbitrary type, but default to Void.
Add _undefined<T>() function, which is like fatalError() but has
arbitrary return type. In playground mode, merely warn about outstanding
placeholders instead of erroring out, and transform placeholders into
calls to _undefined(). This way, code with outstanding placeholders will
only crash when it attempts to evaluate such placeholders.
When generating constraints for an iterated sequence of type T, emit
T convertible to $T1
$T1 conforms to SequenceType
instead of
T convertible to SequenceType
This ensures that an untyped placeholder in for-each sequence position
doesn't get inferred to have type SequenceType. (The conversion is still
necessary because the sequence may have IUO type.) The new constraint
system precipitates changes in CSSimplify and CSDiag, and ends up fixing
18741539 along the way.
(NOTE: There is a small regression in diagnosis of issues like the
following:
class C {}
class D: C {}
func f(a: [C]!) { for _: D in a {} }
It complains that [C]! doesn't conform to SequenceType when it should be
complaining that C is not convertible to D.)
<rdar://problem/21167372>
(Originally Swift SVN r31481)
This case attempts to diagnose assignment into an invalid lvalue which only had
a computable type due to a fixit that the constraint solver was assuming. In this
situation, don't diagnose the invalid lvalue at all, diagnose the required fix.
The desired ExtInfo here is not a clean derivation from either the source or destination ExtInfo anymore, so it's clearer and more maintainable to construct a new EI from whole cloth. Response to @jrose-apple's code review.
- If a @convention(block) function parameter was also marked @noescape, then during type-checking, we would accidentally propagate the convention directly onto a literal closure expr, instead of going through a function_conversion, which SILGen didn't handle. Fixes rdar://problem/23261912.
- If an Objective-C API declared a block parameter with a _Nonnull return of a bridged type, such as NSString *_Nonnull, then native-to-bridged thunking would fail to recognize this case, since we still bridge to an Optional type in the lowered ObjC interface. Fixes rdar://problem/23285766.
This avoids us using reserved identifiers as the enum case names of all
our underscored protocols like _ObjectiveCBridgeable. I used the
convention PROTOCOL_WITH_NAME to mirror how the known identifiers work.
Swift SVN r32924
This removes the partially-correct ABI check in Sema and diagnoses
unsupported conversions in SILGen instead. The new check is more
accurate and correctly diagnoses conversions of DeclRef's to
ABI-incompatible @convention(c) types.
This also fixes two cases where we used to crash but could instead
emit a trivial cast:
- Conversions between ABI-compatible (but not identical)
@convention(c) types
- Conversions of a DeclRef to an ABI-compatible (but not identical)
@convention(c) type
Fixes <rdar://problem/22470105>.
Swift SVN r32163
- Enhance the branch new argument label overload diagnostic to just
print the argument labels that are the problem, instead of printing
the types inferred at the argument context. This can lead to confusion
particularly when an argument label is missing. For example before:
error: argument labels '(Int)' do not match any available overloads
note: overloads for 'TestOverloadSets.init' exist with these partially matching parameter lists: (a: Z0), (value: Int), (value: Double)
after:
error: argument labels '(_:)' do not match any available overloads
note: overloads for 'TestOverloadSets.init' exist with these partially matching parameter lists: (a: Z0), (value: Int), (value: Double)
Second, fix <rdar://problem/22451001> QoI: incorrect diagnostic when argument to print has the wrong type
by specifically diagnosing the problem when you pass in an argument to a nullary function. Before:
error: cannot convert value of type 'Int' to expected argument type '()'
after:
error: argument passed to call that takes no arguments
print(r22451001(5))
^
Swift SVN r31795
change its implementation to take a list of TupleTypeElt for both the
from/to tuple type, but provider a convenience wrapper that takes the
from/to tuple type as TupleType's.
Swift SVN r31733
fixit hint in CSDiags instead of being a FixKind. This resolves a number of issues with
it, particularly that it didn't actually check to see if the function in question takes
a () argument or not.
This fixes:
<rdar://problem/21692808> QoI: Incorrect 'add ()' fixit with trailing closure
among other issues.
Swift SVN r31728
Have ClosureExpr::hasSingleExpressionBody() return true even after the
closure has been coerced to return Void, i.e., { E } has been rewritten
as { E; () }. This fixes some implicit-self diagnostics, and probably
others.
Revision to r31654 for 22441425.
Swift SVN r31665
Introduce a new "OpenedGeneric" locator for when openGeneric opens a generic
decl into a plethora of constraints, and use this in CSDiags to distinguish
whether a constraint refers to an Expr as a whole or an "aspect" of the constraint.
Use that information in FailureDiagnosis::diagnoseGeneralConversionFailure
to know whether (as a fallback) we can correctly re-typecheck an entire expr
to obtain a missing type. If we are talking about an aspect of the expr, then
this clearly won't work.
The upshot of this is that where we previously compiled the testcase in 22519983
to:
y.swift:31:9: error: type '(inout _) -> Bool' does not conform to protocol 'RawRepresentable'
let a = safeAssign
^
we now produce the somewhat more useful:
y.swift:31:9: error: argument for generic parameter 'T' could not be inferred
let a = safeAssign
^
y.swift:27:6: note: in call to function 'safeAssign'
func safeAssign<T: RawRepresentable>(inout lhs: T) -> Bool {
^
Swift SVN r31620
This removes the totally lame diagnostic telling the user to wrap
their function in a closure.
Some exotic Objective-C metatype to AnyObject conversions are still
missing, and there aren't any executable tests yet. Both will be
addressed soon.
Swift SVN r31527
