In light of the invocation limits placed on space subtraction, this grossly incorrect check is being dropped.
Resolves a source of miscompiles in mostly machine-generated code
including SR-6652 and SR-6316.
In Swift 5 mode, CSGen generates a conversion constraint from
the type of OptionalTryExpr's subexpression, call it T, and
Optional<$tv> for a new type variable $tv.
When applying the solution, we would coerce the sub-expression
to T? if T was not optional, or T otherwise. This was wrong
because there's no reason that $tv is actually equal to T.
Instead, we must coerce the sub-expression to Optional<$tv>,
which is the type of the overall OptionalTryExpr.
Fixes <rdar://problem/46742002>.
We allow this sort of thing:
struct Generic<T> {}
typealias Alias = Generic
...
Alias<Int>
However we have to be sure to ban this if the typealias is itself generic, ie
typealias Alias<T> = Generic
Otherwise we will crash.
When a (non-generic) typealias refers to a specialization of a generic
type, e.g.
```swift
typealias simd_float3 = SIMD3<Float>
```
treat an extension of the typealias as an extension of the underlying
type with same-type constraints between the generic parameters and the
specific arguments, e.g.,
```swift
extension simd_float3 { }
```
is treated as
```swift
extension SIMD where Scalar == Float { }
```
This addresses a source-compatibility problem with SE-0229, where
existing types such as simd3_float (which were separate structs)
became specializations of a generic SIMD type.
Fixes rdar://problem/46604664 and rdar://problem/46604370.
For operators with multiple designated types, we attempt to decide the
best order for exploring the types. We were doing this by checking
for matching types. Extend this to also consider conforming types.
Fixes: rdar://problem/46687985
After calling `get{Possible}Type{s}WithoutApplying` types have to be
re-cached afterwards because sanitizer (run as part of the constraint
generator) can mutate AST to e.g. re-introduce member references.
Resolves: rdar://problem/46497155
In 119864a0f5 I moved the consideration
of top-level operators sooner when the designated types feature is
enabled, and that fixed some source compatibility issues that show up
in our test suite, but also introduced a new one.
For maximum source compatibility we'll just split the partitions up
into the operators from designated types, followed by operators that
are not deprecated or disabled, followed by the deprecated ones, and
finally the disabled ones.
Referring to a generic type without arguments inside the definition
of the type itself or an extension thereof is a shorthand for
forwarding the arguments from context:
struct Generic<T> {}
extension Generic {
func makeOne() -> Generic // same as -> Generic<T>
}
However this didn't work if the type was replaced by a typealias:
struct OldGeneric<T> {}
typealias Generic<T> = OldGeneric<T>
extension Generic {
func makeOne() -> OldGeneric // OK
func makeOne() -> Generic // error
}
Add a hack for making this work so that we better cope with the
renaming of DictionaryLiteral to KeyValuePairs in Swift 5.0.
Fixes <rdar://problem/43955962>.
Sema would directly check for the presence of the @objcMembers attribute,
and inherit it from the immediate superclass in validateDecl().
We don't want validateDecl() to have side effects like this and this was
already a problem, because it would not inherit the attribute transitively
in some cases.
Instead, add a ClassDecl::hasObjCMembers() method that walks over all
ancestors and caches the result.
<rdar://problem/46420252>
When the compiler fails to find an overload with suitable parameter or return types, it often attaches a note listing the available overloads so that users can find the one they meant to use. The overloads are currently ordered in a way that depends on the order they were declared, so swift-evolve would sometimes cause tests involving these diagnostics to fail.
This change emits the list in a textually-sorted order instead. The names were already being sorted as they were inserted into a std::set, so this shouldn’t significantly slow down the diagnostic.
Context archetypes and opened existential archetypes differ in a number of details, and this simplifies the overlapping storage of the kind-specific fields. This should be NFC; for now, this doesn't change the interface of ArchetypeType, but should allow some refinements of how the special handling of certain archetypes are handled.
If we're given multiple parameter lists, we don't have to build a
generic signature and environment for each one. Instead, we can
just use a single GenericSignatureBuilder and add all of them in
one shot.
On my iMac Pro, this speeds up the parse_stdlib test from 169
seconds to 133.
GenericParamList::OuterParameters would mirror the nesting structure
of generic DeclContexts. This resulted in redundant code and caused
unnecessary complications for extensions and protocols, whose
GenericParamLists are constructed after parse time.
Instead, lets only use OuterParameters to link together the multiple
parameter lists of a single extension, or parameter lists in SIL
functions.
When -Xfrontend -solver-enable-operator-designated-types is enabled,
attempt operators defined outside of types before attempting operators
defined within (non-designated) types.
This helps fix some source compatability problems that arise from
attempting some of the operators defined for Optional (e.g. we
would sometimes typecheck successfully with the operator for Optional
and then inject values into Optionals and skip attempting
globally defined operators that also match).
The old behavior resulted in failures in SourceKit and SIL Optimizer
tests when enabling designated types by default in our test suite.
Previously the cast optimizer bailed out on any conformance with
requirements.
We can now constant-propagate this:
```
protocol P {}
struct S<E> {
var e: E
}
extension S : P where E == Int {}
func specializeMe<T>(_ t: T) {
if let p = t as? P {
// do fast things.
}
}
specializeMe(S(e: 0))
```
This turns out to be as simple as calling the TypeChecker.
<rdar://problem/46375150> Inlining does not seem to handle
specialization properly for Data.
This enabled two SIL transformations required to optimize
the code above:
(1) The witness method call can be devirtualized.
(2) The allows expensive dynamic runtime checks such as:
unconditional_checked_cast_addr Array<UInt8> in %array : $*Array<UInt8> to ContiguousBytes in %protocol : $*ContiguousBytes
Will be converted into:
%value = init_existential_addr %existential : $*ContiguousBytes, $Array<UInt8>
store %array to %value : $*Array<UInt8>
The new SIMD proposal introduced a number of new operators, the presence of
which causes more "expression too complex" failures. Route around the
problem by de-prioritizing those operators, visiting them only if no
other operator could be chosen. This should limit the type checker
performance cost of said operators to only those expressions that need
them OR that already failed to type-check.
Fixes rdar://problem/46541800.
This helps maintain invariants, such as the presence of a generic
parameter list implying the presence of a generic signature.
Fixes <rdar://problem/45317855>.
For now Sema still calls it manually, but soon we could make
getGenericParams() lazy, calling this automatically, since
there's really no reason to create the generic parameters
upfront when binding the extension.
We were previously doing it in the validateDecl() path, which is
unnecessary, because they're all invalid. So move the "checking"
to typeCheckDecl() so we only do it for primary files.
