We currently permit (but warn on) coercions of
collections with unrelated element types in
certain cases. This is done in an effort to preserve
compatibility with pre-5.3 compilers that may have
allowed such code to compile due to dropping
constraints while solving.
This is limited to collection coercions as we
emit somewhat reasonable code for them that
performs a force cast of the elements at runtime.
However, it turns out that in the case of collection
literals, we peephole the element conversions in
CSApply, leading to codegen crashes. As such,
narrow down the condition of this compatibility
logic to not apply to collection literals, as this
never would have compiled properly.
rdar://88334481
To help support incremental adoption of the concurrency model, a number
of concurrency-related diagnostics are enabled only in "new" code that
takes advantage of concurrency features---async, @concurrent functions,
actors, etc. This warning flag opts into additional warnings that better
approximate the eventual concurrency model, and which will become
errors a future Swift version, allowing one to both experiment with
the full concurrency model and also properly prepare for it.
* [Sema] Implementing is runtime check always true diagnostic as a fix
* [AST] Implement getWithoutThrows on function type
* [CSSimplify] Detect that checked cast types conversion is always true and record warning fix
* [test] Some additional test cases for SR-13789
* [Sema] Fixing typo on fix name
* [Sema] Move and adjust the ConditionalCast diagnostics to the fix format
* [Sema] Remove some checked cast diagnostics from check constraints and move to fix
* [Sema] Renaming checked cast coercible types fix
* [Sema] Some adjustments and rewrite on the logic for downcast record fix
* [Sema] Move logic of runtime function type to AllowUnsupportedRuntimeCheckedCast::attempt
* [Sema] Abstract checked cast fix logic to static function and minor adjustments
* [Sema] Renamings from review
Generally, casting consistency demands that we be able
to extract anything from an existential that can be put
into that existential. (Which is why the casting spec
requires that casting permit arbitrary injection and
projection of optionals.)
This particular diagnostic prevented optionals from being
projected back out of existentials:
let i: Int?
let a: Any = i // Inject Int? into Any
// Error prevents projecting Int? back out of Any
a as? Int?
This also broke certain uses of Mirror (weak variables get reflected as
optionals stored in Any existentials).
* [TypeCheckConstraints] Adjusting cases where checked casts that cannot be determined statically were producing misleading warnings
* [tests] Adding regression tests for SR-13088
* [TypeCheckConstraints] Adjusting comment and adding an extra test case for SR13035
* [TypeCheckConstraints] Fixing typos in comments
* [AST] Moving implementation of isCollection from ConstraintSystem to AST TypeBase
* [TypeCheckConstraints] Adjusting logic to verify specific conformance to stdlib collection type before emit an downcast warning
* [TypeCheckConstraints] Creating new CheckedCastContextKind::CollectionElement to be able to verify special cases within typeCheckCheckedCast for collection elements
* [TypeCheckConstraints] Adjusting logic around generic substitution to check both subtype and supertype
* [Sema] Adding isKnownStdlibCollectionType and replacing all usages contraint system method
* [TypeChecker] Reverting fixes around array element types
* [TypeChecker] Abstract logic of check for conditional requirements on TypeChecker::couldDynamicallyConformToProtocol
* [TypeChecker] Ajdustinc can conformDynamically conform and adjust review comments
* [TypeChecker] Ajusting comments and fixing typos
* [TypeChecker] Adjusting existential and archetype logic to check inside couldDynamicConform
* [TypeChecker] Adjusting minor and adding existential check into couldDynamically conform.
* [TypeChecker] Adjusting comments
Previously we could allow some invalid coercions to
sneak past Sema. In most cases these would either
cause crashes later down the pipeline or
miscompiles. However, for coercions between
collections, we emitted somewhat reasonable code
that performed a force cast.
This commit aims to preserve compatibility with
those collection coercions that previously
compiled, and emits a warning telling the user to
use either 'as?' or 'as!' instead.
Start visiting transitive fixed bindings for type
variables, and stop visiting adjacencies for
`gatherConstraint`'s `AllMentions` mode.
This improves performance and fixes a correctness
issue with the old implementation where we could
fail to re-activate a coercion constraint, and
then let invalid code get past Sema, causing
either miscompiles or crashes later down the
pipeline.
Unfortunately this change requires us to
temporarily drop the non-ephemeral fix for a couple
of fairly obscure cases where the overload hasn't
yet been resolved. The logic was previously relying
on stale adjacency state in order to re-activate
the fix when the overload is bound, but it's not
connected on the constraint graph. We need to find
a way to connect constraints to unresolved
overloads they depend on.
Resolves SR-12369.
Based on the checked cast behavior don't warn about unrelated
casts between tuples unless their sizes or labels differ.
Resolves: rdar://problem/56436235
When re-typechecking an expression during diagnostics, we begin by
erasing all the types in the expression. However, any expressions
created as part of applying the solution will remain.
CSGen was doing the wrong thing when it encountered EnumIsCaseExpr,
which can only appear in already-type checked ASTs.
Returning expr->getType() is not correct, because the type is not
yet set; returning a null type is intended to signal that a
diagnostic was already emitted, which causes Sema to stop
type checking.
The end result is that certain combinations of invalid code with
an 'is' cast nested inside would crash either the AST verifier
(with asserts on) or in SILGen (with asserts off), because we
would stop trying to diagnose the issue prematurely, and possibly
not emit a diagnostic at all.
Fixes <https://bugs.swift.org/browse/SR-5050> and
<rdar://problem/32487948>.
Checked casts are dependent on run-time queries; we should not attempt
to infer type variable bindings from them, because doing so produces
unreasonable bindings. Fixes rdar://problem/29894174.
Specialize and improve the "downcast only unwraps optionals"
diagnostic to provide specific diagnostics + Fix-Its for the various
casts of forced cast, conditional cast, and "isa" check. Specifically:
* With a forced cast, customize the diagnostic. We still insert the
appropriate number of !'s, but now we remove the 'as! T' (if an
implicit conversion would suffice) or replace the 'as!' with 'as'
(if we still need a bridge)
* With a conditional cast, only emit a diagnostic if we're removing
just one level of optional. In such cases, we either have a no-op
(an implicit conversion would do) or we could just use 'as' to the
optional type, so emit a customized warning to do that. If we are
removing more than one level of optional, don't complain:
conditional casts can remove optionals. Add the appropriate Fix-Its
here.
* With an 'is' expression, only emit a diagnostic if we're removing
just one level of optional. In this case, the 'is' check is
equivalent to '!= nil'. Add a Fix-It for that.
Across the board, reduce the error to a warning. These are
semantically-well-formed casts, it's just that they could be written
better.
Fixes rdar://problem/28856049 and rdar://problem/22275685.
This commit defines the ‘Any’ keyword, implements parsing for composing
types with an infix ‘&’, and provides a fixit to convert ‘protocol<>’
- Updated tests & stdlib for new composition syntax
- Provide errors when compositions used in inheritance.
Any is treated as a contextual keyword. The name ‘Any’
is used emit the empty composition type. We have to
stop user declaring top level types spelled ‘Any’ too.
Previously, a type that conformed to 'Error' could not be bridged to
NSError directly. Rather, one would have to go through the 'Error'
protocol, e.g.,
myErrorValue as Error as NSError
rather than
myErrorValue as NSError
Make the latter work.
allowing these failures to hook into other diagnostic goodies (e.g. the
"did you mean to use '!' or '?'?" cases showing in the testsuite). That said,
by itself this doesn't have a huge impact, but avoids regressions with other
pending changes.
Swift SVN r31289
