- Most immediately, we now have `withoutActuallyEscaping` as a supported way to temporarily reference a nonescaping closure as if it were escapable, and we plan to break the ABI for escaping and nonescaping closures so that the old `unsafeBitCast` workaround no longer works.
- `unsafeBitCast` is also commonly used to kludge pointers into different types, but we have more semantically meaningful APIs for type punning now. Guide users towards those APIs.
- Suggest more specific and type-safe operations, like `bitPattern:` initializers or `unsafeDowncast`, for the situations where `unsafeBitCast` is being used to avoid dynamic type checks or reinterpret numerical bits.
Several fixes in order to make handling of types more consistent.
In particular:
- Expression types used within the constraint system itself always use
the type map.
- Prior to calling out to any TypeChecker functions, the types are
written back into the expression tree. After the call, the types are
read back into the constraint system type map.
- Some calls to directly set types on the expressions are reintroduced
in places they make sense (e.g. when building up new expressions that
are then passed to typeCheckExpressionShallow).
ConstraintSystem::setType() is still setting the type on the expression
nodes at the moment, because there is still some incorrect handling of
types that I need to track down (in particular some issues related to
closures do not appear to be handled correctly). Similarly, when we
cache the types in the constraint system map, we are not clearing them
from the expression tree yet.
The diagnostics have not been updated at all to use the types from
the constraint system where appropriate, and that will need to happen as
well before we can remove the write from ConstraintSystem::setType()
into the expression and enable the clearing of the expression tree type
when we cache it in the constraint system.
* Pack the bits for IfConfigDecls into Decl
* Don't open symbols into a module when evaluating canImport statements
The module loaders now have API to check whether a given module can be
imported without importing the referenced module. This provides a
significant speed boost to condition resolution and no longer
introduces symbols from the referenced module into the current context
without the user explicitly requesting it.
The definition of ‘canImport’ does not necessarily mean that a full
import without error is possible, merely that the path to the import is
visible to the compiler and the module is loadable in some form or
another.
Note that this means this check is insufficient to guarantee that you
are on one platform or another. For those kinds of checks, use
‘os(OSNAME)’.
Previously this would cause strange diagnostics to be emitted when
values of type Bool! were the subject of if-expression conditions.
var isBoolean: Bool! = false
let conditional = isBoolean ? "Broken" : "Heart"
// ^ type 'Bool' is broken
Instead, look through IOUs before performing the member access to cover
our bases here.
These are used from within constraint system code, and for those uses we
need to be reading from the constraint system type map.
Add the parallel constraint system interfaces that call into the
Expr interfaces with the appropriate accessors.
Not really specific to typealiases; but we don't allow nominal types
to be nested inside protocols yet, and all other types of protocol
members have witnesses in the concrete type.
Fixes <https://bugs.swift.org/browse/SR-2792>.
Previously all of the following would strip off varying amounts of
MetatypeType, LValueType, InOutType, DynamicSelfType, etc:
- ConstraintSystem::performMemberLookup()
- ConstraintSystem::lookupMember()
- TypeChecker::lookupMember()
- DeclContext::lookupQualified()
- Type::getContextSubstitutions()
The problem is that the higher level methods that took a lookup type
would call the lower level methods, and post-process the result using
the given lookup type. Since different levels of sugar were stripped,
it made the code hard to reason about and opened up edge cases, eg
if a DynamicSelfType or InOutType appears where we didn't expect it.
Since filtering out static/instance and mutating/nonmutating members
is done at higher levels, there's no reason for these name lookup
operations to accept anything other than nominal types, existentials
and archetypes.
Make this so with assertions, and deal with the fallout.
- TypeMatchVisitor doesn't like seeing ErrorTypes -- stop if we have one.
- Common logic for replacing type parameters and variables with
UnresolvedType.
- Fix crash in coerceToType() if one of the two types has an UnresolvedType
in it, but not at the top level.
Fixes one compiler_crasher and some regressions with upcoming patches.
Not sure why but this was another "toxic utility method".
Most of the usages fell into one of three categories:
- The base value was always non-null, so we could just call
getCanonicalType() instead, making intent more explicit
- The result was being compared for equality, so we could
skip canonicalization and call isEqual() instead, removing
some boilerplate
- Utterly insane code that made no sense
There were only a couple of legitimate uses, and even there
open-coding the conditional null check made the code clearer.
Also while I'm at it, make the SIL open archetypes tracker
more typesafe by passing around ArchetypeType * instead of
Type and CanType.
We might allow protocols inside non-generic class/struct/enum
declarations eventually; there's no conceptual difficulty, just
some IRGen and Serialization work that has to happen first.
Also, this fixes a crasher :-)
We would falsely diagnose the occurrence of the protocol
_in the inheritance clause_ as a "bad" usage of an
existential type, because the UnsupportedProtocolVisitor
was too eager in walking into nested Decls and Stmts.
Note that in one case we don't emit a diagnostic where we
did before, but this doesn't matter; the VarDecl in
question becomes invalid later, and only the order in
which the decls are visited changes.
When inserting a new value, assert that there's no existing
value at that key, and to avoid the assert firing when
opening up UnboundGenericTypes, put those replacements in
their own map. We don't need them later.
Protocol methods returning optionals, metatypes and functions
returning 'Self' are now handled correctly in Sema when
accessed with a base of existential type, eg:
protocol Clonable {
func maybeClone() -> Self?
func cloneMetatype() -> Self.Type
func getClonerFunc() -> () -> Self
}
let c: Clonable = ...
let _: Clonable = c.maybeClone()
let _: Clonable.Type = c.cloneMetatype()
Previously, we were unable to model this properly, for
several reasons:
- When opening the function type, we replaced the return
value in openedFullType _unconditionally_ with the
existential type. This was broken if the return type
was not the 'Self' parameter, but rather an optional,
metatype or function type involving the 'Self' parameter.
- It was also broken because we lost information; if the
return type originally contained an existential, we had
no way to draw the distinction. The 'hasArchetypeSelf()'
method was a hint that the original type contained a
type parameter, but it was inaccurate in some subtle cases.
- Since we performed this replacement on both the
'openedFullType' and 'openedType', CSApply had to "undo"
it to replace the existential type with the opened
existential archetype. This is because while the formal
type of the access returns the existential type, in
reality it returns the opened type, and CSApply has to
insert the correct ErasureExpr.
This was also done unconditionally, but even if it were
done more carefully, it would do the wrong thing because
of the 'loss of information' above.
- There was something fishy going on when we were dealing
with a constructor that was declared on the Optional type
itself, as seen in the fixed type_checker_crasher.
- TypeBase::eraseOpenedExistential() would transform a
MetatypeType of an opened existential into a MetatypeType
of an existential, rather than an ExistentialMetatypeType
of the existential type.
The new logic has the following improvements:
- When opening a function type, we replace the 'Self' type
parameter with the existential type in 'openedType', but
*not* 'openedFullType'. This simplifies CSApply, since it
doesn't have to "undo" this transformation when figuring
out what coercions to perform.
- We now only use replaceCovariantResultType() when working
with Self-returning methods on *classes*, which have more
severe restrictions than protocols. For protocols, we walk
the type using Type::transform() and handle all the cases
properly.
- Not really related to the above, but there was a whole
pile of dead code here concerning associated type references.
Note that SILGen still needs support for function conversions
involving an existential erasure; in the above Clonable example,
Sema now models this properly but SILGen still crashes:
let _: () -> Clonable = c.getClonerFunc()
Fixes <rdar://problem/28048391>, progress on <rdar://problem/21391055>.
When we have a value 'p' of type 'P.Type' for some protocol 'P',
we require the user to write 'p.init()' rather than 'p()' to
construct an instance of a concrete type conforming to 'P'.
If they write 'p()', we suggest a fixit to insert '.init',
however if there is also a subsequent member access on the
result, for example 'p().foo', we would crash.
Another invalid case that used to crash is when you construct
a protocol metatype directly and then access a member of it,
eg. 'P().foo'.
The ForeignErrorConvention calculation didn't take the special
case isObjCZeroParameterWithLongSelector() constructors into
account.
Fixes <https://bugs.swift.org/browse/SR-1713>.
We have an implicit conversion where a closure with a non-Void
result type can be passed as a function value with a Void
result; this makes single-expression closures more usable in
the case where you want the single expression to be a
statement -- discarding it's result.
Unfortunately we were checking if the locator contains a
ClosureResult component *anywhere* in the path. This is too
permissive. The correct check is that the *last* path component
is a ClosureResult.
Otherwise, we happily convert anything to () *anywhere*
in a closure result, which crashes immediately in SILGen.
Fixes <https://bugs.swift.org/browse/SR-403>.
Currently if destination is unresolved instead of trying to re-typecheck
it again and diagnose structural problems which led to such outcome, it
gets completely ignored in favor of trying to type-check source without
contextual type. That leads to missed diagnostic opportunities, which
results in problems on AST verification and SIL generation stages, and
generally missleading errors e.g. `.x = 0`.
Resolves: SR-3506.
