There is a short-circuiting hack in the constraint solver that speeds up
solving, but isn't generally sound. If we allow unavailable decls to be
considered "favored", this can fire and result in our choosing a
solution that involves the unavailable decl where other solutions exist.
Fixes rdar://problem/32570734.
This time, the warnings only fire when the class in question directly
conforms to NSCoding. This avoids warning on cases where the user has
subclassed something like, oh, UIViewController, and has no intention
of writing it to a persistent file.
This also removes the warning for generic classes that conform to
NSCoding, for simplicity's sake. That means
'@NSKeyedArchiverEncodeNonGenericSubclassesOnly' is also being
removed.
Actually archiving a class with an unstable mangled name is still
considered problematic, but the compiler shouldn't emit diagnostics
unless it can be sure they are relevant.
rdar://problem/32314195
This is accomplished by recognizing this specific situation and
replacing the 'objc' attribute with a hidden '_objcRuntimeName'
attribute. This /only/ applies to classes that are themselves
non-generic (including any enclosing generic context) but that have
generic ancestry, and thus cannot be exposed directly to Objective-C.
This commit also eliminates '@NSKeyedArchiverClassName'. It was
decided that the distinction between '@NSKeyedArchiverClassName' and
'@objc' was too subtle to be worth explaining to developers, and that
any case where you'd use '@NSKeyedArchiverClassName' was already a
place where the ObjC name wasn't visible at compile time.
This commit does not update diagnostics to reflect this change; we're
going to change them anyway.
rdar://problem/32414557
Update CSDiag.cpp to use the constraint system's type map instead of
directly reading types from expressions.
As with past commits, the type map is not really enabled yet since we
still write types directly into expressions in the constraint solver.
Instead of having three different scores for - string, array, inout,
let's unify them under a single value-to-pointer score and use
it in appropriate places when simplifying restricted constraints.
Covers some common situations when switching from literal types e.g.
string or int to more Swift Way of raw representable enum of choices.
Resolves: rdar://problem/32431165, rdar://problem/31977537, rdar://problem/32432253
Warn about uses of declarations which have inferred @objc due to the
deprecated Swift 3 rules when the declarations are used to satisfy a
requirement of an @objc protocol. This covers cases where the @objc
cannot be inferred due to the conformance, e.g., when the declaration
itself is in a superclass but a subclass is stating the conformance.
Fixes rdar://problem/32431838.
This was previously handled very late, by the type checker, which led
to weird ordering dependencies and meant that we could end up with
well-formed code where the GSB was left with unresolved types. We want
such states to never exist, so make sure we can resolve everything in
the GSB.
Conditional and forced downcasts enter a constraint that almost
always succeeds; only when applying the solution do we evaluate
the feasability of the cast and determine if it always succeeds,
always fails, or conditionally succeeds. This changes how the
resulting AST is represented and can also emit diagnostics.
If the conditional cast is at this stage determined to always
succeed, we treat it as an unconditional cast, going through
ExprRewriter::coerceToType() to build the AST for the coercion.
However conditional cast constraints don't enter the same
restrictions into the solution as unconditional casts do, so
coerceToType() would fall over if casting a Swift type to a CF
type by first bridging the Swift type to Objective-C.
Get around this by checking for this case explicitly when
lowering a CoerceExpr.
It feels like there's a more fundamental issue here with how
casts are modeled in the constraint solver, but I'm not going
to try understanding that now.
Fixes <rdar://problem/32227571>.
If we fail when doing a coercion while generating an OpenExistentialExpr
when applying a solution during type checking, make sure that the opaque
value on that OpenExistentialExpr is cleared.
We do not visit these during normal AST walks because they normally
appear in the subexpression held by the OpenExistentialExpr. In this
case, however, we replace that subexpression with an ErrorExpr which
means we will not visit the opaque value at all, so certain operations,
like setting the type on the opaque value, will never happen, and we can
run into problems later by code that assumes the type is set.
It seems reasonable to just clear these out in cases like this since
they are not reachable by any normal means.
(...is constrained to be a subtype of another)
Previously the compiler would just mark the entry in the inheritance
clause invalid and move on without emitting any errors; in certain
circumstances in no-asserts builds this could actually lead to
everything working "correctly" if all conforming types happened to
pick the same concrete type for both associated types. In Swift 4 this
can actually be enforced with a same-type requirement, which will
guarantee that the two associated types are the same even in generic
contexts.
This fix avoids assertions and crashes, but the diagnostic is still
incorrect, and in the simple case of the inheritance clause it's
redundant. Doing something better and possibly even downgrading it to
a warning in Swift 3 mode is tracked by rdar://problem/32409449.
Initial patch by Slava, fixed up by me.
There are possible situations when we find solutions with String
and String -> UnsafePointer conversions at the same time for
expressions with default string literals. In order to disambiguite
such situations let's prefer solutions without String -> UnsafePointer
conversions if possible.
Restrict skipping of the generic overloads only to the situations
when non-generic solution doesn't have any restrictions/fixes, because
there is a possibility that generic overload could produce a better
solution.
Resolves: rdar://problem/32204609.
`FreeTypeVariableBinding::GenericParameters` mode allowed to bind
all free type variables with fresh generic parameter types, which
is incorrect (at least) if there are multiple generic solutions
present, because such parameters couldn't be compared.
This mode was used for code completion, which is now switched to use
`FreeTypeVariableBinding::UnresolvedType` instead.
Potential archetypes can resolve to either an associated type or a
typealias. Generalize the latter to "any concrete type", both because
the current implementation is unnecessarily narrow (typealiases aren't
actually special in this regard) and to get us closer to handling
lookups via superclass constraints when resolving these types.
If the contextual closure type expects no parameters but N
parameters where used and all of the them are anonymous, let's
suggest removing them.
Resolves: rdar://problem/32432145
We cannot model a type variable bound to the ExtInfo of a function
type in the constraint solver, which means we have a hard time
propagating noescape-ness in some cases.
Fixes <rdar://problem/31910280> and <rdar://problem/32409133>.
<rdar://32480026>
This is a particularly tricky tradeoff to have to make here. On the one
hand, we want diagnostics about incomplete patterns to provide as much
information as possible. On the other, pattern matrices grow
quasi-factorially in the size of the argument. That is, an enum with 10
cases that is switched on as a 2-tuple/argument list creates a total
subspace covering of size 100. For sufficiently large inputs, this can
DOS the Swift compiler.
It is simply not useful to present more than about 100 notes to the
user, nor is it useful to waste an enormous amount of time trying to
compute these subspaces for the limited information the diagnostic will
provide. Instead, short circuit if the size of the enum is above some
arbitrary threshold (currently 128) and just offer to add a 'default'.
Notably, this change is not *technically* source compatible in that it
ignores the new '@_downgrade_exhaustivity_check'. However to hit up
against this heuristic would require the user to be switching over four
DispatchTimeIntervals in a quadruple or using an equivalently-sized
enormous enum case. At which point we're hitting on the very reason
this heuristic exists.
There are definitely other, more informative, paths that we can take
here. GHC, for example, seems to run a highly limited form of space
subtraction when the input space is too large, and simply reports the
top 3 missing cases along with some ellipses. For now, I just want to
cut off this hang in the compiler.
Situations where there is a contextual RawRepresentable type is
used incorrectly would produce `<Type>(rawValue: )` fix-it only
in cases where neither or both sides of the expression are optional.
Let's fix that by adding a fix-it for optional to contextual raw
value type conversion.
Resolves: rdar://problem/32431736
Add additional checking for complexity of the shrinking candidate
given the number of the expressions solved so far and total number
of disjunctions present. This allows us to bail quicker in complex
expression cases which, at the very least, produces an error instead
of being "stuck" in solver for a long time.
Resolves: rdar://problem/32034560
This conversion just existed to aid migration from Identifier to
DeclBaseName and is no longer needed. It will technically not even be
correct once special names are introduced.
Push the getName method from ValueDecl down to only those types that are
guaranteed to have a name that is backed by an identifier and that will
not be special.
Adjust the definition of some diagnostics that are already called with
DeclBaseNames so that the implicit conversion from DeclBaseName to
Identifier is no longer needed.
Adjust the call side of diagnostics which don't have to deal with
special names to pass an Identifier to the diagnostic.
More updates to read and write types from a side table in the constraint
solver and only write back into expressions when we've finished type
checking an expression.
We still write directly into expressions, and will continue to do so
until all of the code has been updated.
