I don't have reduced test cases. The original test cases
were a series of frontend invocations in -parse-stdlib
mode.
While the original bugs seem to have been fixed, while
verifying I found a few places where we weren't checking
for null decls property in the ASTContext.
Probably not too useful to check this in, but I don't see it
causing any harm, either.
To remove some callers of 'is<InOutType>' after Sema, start using what will soon be a structural invariant - the only expressions that can possibly have 'inout' type are semantically InOut expressions.
As a step toward eliminating the single input type
representation of function parameters, add more constraints on that
input type. It can be one of:
* A tuple type, for multiple parameters,
* A parenthesized type, for a single parameter, or
* A type variable type, for specific cases in the type checker
Enforce these constraints for *canonical* types as well, so the
canonical form of:
typealias MyInt = Int
typealias MyFuncType = (MyInt) -> Int
is now:
(Int) -> Int
rather than:
Int -> Int
This affects canonicalization of FunctionType and
GenericFunctionType. Enchance both, as well as their Can*Type
counterparts, with "get" operators that take an array of
AnyFunctionType::Param, and start switching a few clients over to this
new, preferred API.
AnyFunctionType::Param carries around information about decomposed
parameters now. Information about default arguments must be computed
separately with swift::computeDefaultMap.
In anticipation of removing this bit, move it from the
recursive type property into TupleType - its only real
user. This necessitates uglifying a bit of logic in the
short term that used to speak broadly of materializability
to instead speak about LValues and Tuples of InOut values
independently.
With the introduction of special decl names, `Identifier getName()` on
`ValueDecl` will be removed and pushed down to nominal declarations
whose name is guaranteed not to be special. Prepare for this by calling
to `DeclBaseName getBaseName()` instead where appropriate.
This changes `getBaseName()` on `DeclName` to return a `DeclBaseName`
instead of an `Identifier`. All places that will continue to be
expecting an `Identifier` are changed to call `getBaseIdentifier` which
will later assert that the `DeclName` is actually backed by an
identifier and not a special name.
For transitional purposes, a conversion operator from `DeclBaseName` to
`Identifier` has been added that will be removed again once migration
to DeclBaseName has been completed in other parts of the compiler.
Unify approach to printing declaration names
Printing a declaration's name using `<<` and `getBaseName()` is be
independent of the return type of `getBaseName()` which will change in
the future from `Identifier` to `DeclBaseName`
Instead, introduce a new hasDependentMember() recursive property.
The only place that cares about this is associated type inference,
where I changed all existing hasTypeParameter() checks to instead
check (hasTypeParameter() || hasDependentMember()). We could
probably refine this over time and remove some of the
hasTypeParameter() checks, but I'm being conservative for now.
Fixes <https://bugs.swift.org/browse/SR-4575> and
<rdar://problem/31603113>.
A `GenericSignatureBuilder` only needs to be finalized when we need to
compute a generic signature from it or otherwise require diagnostics.
Canonical generic signature builders don’t need either of those, so unless we
are performing the expensive idempotency checking, only do the minimal work
to “process delayed requirements”.
This gives a 3x speedup in type-checking time for the “trivial” example
let x = [1, 2]
because we do a lot less work on deserialization of generic environments.
Part of rdar://problem/32116933.
Rather than having `ASTContext:: getOrCreateCanonicalGenericEnvironment()`
ask its `GenericSignatureBuilder` parameter recompute the generic signature
at nontrivial cost, just pass the known signature through.
When casting from an object type to a bridged Swift value type, classifyDynamicCast would use the cast classification for the target type's bridged object type, which would be trivially WillSucceed for thinks like NSNumber-to-Int or NSError-to-SomeError, even though the bridging itself could fail. Fixing this fixes SR-2920|rdar://problem/31404281.
Like NSObject, CFType has primitive operations CFEqual and CFHash,
so Swift should allow those types to show up in Hashable positions
(like dictionaries). The most general way to do this was to
introduce a new protocol, _CFObject, and then have the importer
automatically make all CF types conform to it.
This did require one additional change: the == implementation that
calls through to CFEqual is in a new CoreFoundation overlay, but the
conformance is in the underlying Clang module. Therefore, operator
lookup for conformances has been changed to look in the overlay for
an imported declaration (if there is one).
This re-applies 361ab62454, reverted in
f50b1e73dc, after a /very/ long interval
where we decided if it was worth breaking people who've added these
conformances on their own. Since the workaround isn't too difficult---
use `#if swift(>=3.2)` to guard the extension introducing the
conformance---it was deemed acceptable.
https://bugs.swift.org/browse/SR-2388
Replace `NameOfType foo = dyn_cast<NameOfType>(bar)` with DRY version `auto foo = dyn_cast<NameOfType>(bar)`.
The DRY auto version is by far the dominant form already used in the repo, so this PR merely brings the exceptional cases (redundant repetition form) in line with the dominant form (auto form).
See the [C++ Core Guidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#es11-use-auto-to-avoid-redundant-repetition-of-type-names) for a general discussion on why to use `auto` to avoid redundant repetition of type names.
If SubstitutionMap is asked to form a substitution for a generic
parameter that has been made concrete by the generic signature,
substitute into the concrete type. This allows us to better deal with
non-canonical types.
Add CGFloat (and other types that this applies to) as a trivial type even after
the one-time initialization of the ForeignRepresentableCache.
This allows
let str = ""
import Foundation
let pt = CGPoint(x: 1.0, y: 2.0)
to work.
Before we would populate the cache the first time on the first line "let str =
..." and because the CoreGraphics module was not loaded we would not add CGFloat
as a trivial type. When we come to query for CGFloat on the third line we would
return NSNumber instead of CGFloat as a type and that would crash IRGen.
rdar://31610342
The set of SILBoxType’s generic arguments should be canonical, otherwise getCanonicalType() produces wrong results.
It does not contain a reduced test-case, because the actual bug happens when compiling the stdlib on one of the experimental branches and requires a rather complex setup. I'll try to provide a test-case later.
Resolves one of the issues in rdar://31603112
There were various problems with layout constraints either
being ignored or handled incorrectly. Now that I've exercised
this support with an upcoming patch, there are some fixes
here.
Also, introduce a new ExistentialLayout::getLayoutConstriant()
which returns a value for existentials which are class-constrained
but don't have a superclass or any class-constrained protocols;
an example would be AnyObject, or AnyObject & P for some
non-class protocol P.
NFC for now, since these layout-constrained existentials cannot
be constructed yet.
Add a 'hasExplicitAnyObject()' bit to ProtocolCompositionType
to represent canonical composition types containing '& AnyObject'.
Serialize this bit and take it into account when building
ExistentialLayouts.
Rename ProtocolCompositionType::getProtocols() to getMembers()
since it can contain classes now, and update a few usages that
need further attention with FIXMEs or asserts.
For now, nothing actually constructs these types, and they will
trigger arounds asserts. Upcoming patches will introduce support
for this.
Don't assume all members are existential types; we could have
a class (or a class-constrained existential) also, and this
needs to be handled.
When building a canonical protocol composition, the subclass
requirement always comes first in the list of types. This is
an important invariant allowing ExistentialLayout to be
calculated quickly.
Also, calculate the recursive properties of the composition
type from the recursive properties of its members, since they're
no longer trivial if the composition contains a class member
with generic parameters.
This consolidates calculations which need to look at every
protocol in an existential type. Soon we will also have to
deal with superclass constrained existentials, so start
updating call sites that look at all protocols to use the
new ExistentialLayout and correctly handle a class constraint
as well.
Also, eventually I will kill off the AnyObject protocol and
model it as a protocol composition with no protocols or
superclass, but the requiresClass() flag set.
This is not quite modeled this way yet and AnyObject still
exists, but the new abstraction is a step in the right
direction.
- Add support for _Class and _NativeClass layout constraints, which are supposed to represent T: Superclass and P: class constraints in the future.
- Use the re-factoring to also reduce the number of dynamic allocations when creating layout constraints. Simple non-parametrized layout constraints are now represented as statically allocated singletons (static members of LayoutConstraintInfo).
A lot of files transitively include Expr.h, because it was
included from SILInstruction.h, SILLocation.h and SILDeclRef.h.
However in reality most of these files don't do anything
with Exprs, especially not anything in IRGen or the SILOptimizer.
Now we're down to 171 files in the frontend which depend on
Expr.h, which is still a lot but much better than before.
The new DeclBaseName type will later be able to hold either normal
identifiers (as they exist now) or special names that don't have an
identifier (like subscripts)
