Conformances that discoverably for a type parameter via a superclass
requirement occupy a bit of a gray area in the type checker and
generic signature handling right now: we have a type parameter (so the
paths that handle concrete conformances don't kick in), but the
conformance itself isn't modeled as a requirement because it is
available via lookup. Teach SubstitutionMap's conformance lookup to
detect this case and perform conformance lookup in the generic
signature (i.e., falling back to global lookup) in this case,
replicating the hack that IRGen uses to address the same issue when
accessing the conformance (see GenArchetype.cpp's TODO where we lookup
a conformance on the superclass). The removal of that hack (as well as
this one) are tracked by rdar://problem/34609744.
For now, fixes SR-7072 / rdar://problem/37904576.
Type checker didn't handle the safe of disjoint optional chaining when trying
to convert such chaining into `.Some` cases, which leads to dangling
`BindOptionalExpr` in the AST.
Resolves: rdar://problem/35870863
I can't see how we'd ever get this wrong at this point, but way back
in the early days of incremental builds we apparently managed to.
Adding a test just to close this out.
rdar://problem/23148987
Restore (un-revert) sting comparison, with fixes
More exhaustive testing of opaque strings, which consistently reproduces prior sporadic failure. Shims fixups. Some test tweaking.
The GenericSignatureBuilder is allowing unresolved dependent member
types to creep into generic signatures, which eventually blows up in
name mangling. Prefer to pick dependent member types that are
fully-resolved when choosing anchors.
This is a spot fix; a better approach would eliminate the notion of
unresolved dependent member types entirely from
PotentialArchetype. That's tracked by rdar://problem/35839277.
Fixes rdar://problem/36549499.
This is useful for explicit casts and type expressions, where
type loc and expression types might be different, and allows
constraint solver to avoid setting opened types to expressions
which resolves multiple crashes.
The current implementation isn't really useful in the face of generic
overloads. It has never been enabled by default, and isn't useful to
keep around if it is disabled. If we ever want to bring it back,
we know where to look!
When we form an overload set containing two generic functions, where
one is more specialized than the other, "favor" the more-specialized
function in the constraint system so we won't explore any paths
involving the less-specialized function when the more-specialized
version applies. This should be a strict improvement, because
previously we would have always gone down both paths.
Fixes rdar://problem/37371815, taking this exponential example linear.
When bindings are picked for particular type variable, right-hand
side of the binding might be another type variable wrapped into optional
type, when trying to determine if both sides of the binding have the
same l-valueness it's imperative to look throught optional type of the
right-hand side. Otherwise new binding might be effectively unsolvable.
Resolves: rdar://problem/37291371
If one of the cases is invalid, let's mark parent enum as invalid
as well, and avoid trying to derive any conformances related to it.
Resolves: rdar://problem/36989792
* Make Range conditionally a Collection
* Convert ClosedRange to conditionally a collection
* De-gyb Range/ClosedRange, refactoring some methods.
* Remove use of Countable{Closed}Range from stdlib
* Remove Countable use from Foundation
* Fix test errors and warnings resulting from Range/CountableRange collapse
* fix prespecialize test for new mangling
* Update CoreAudio use of CountableRange
* Update SwiftSyntax use of CountableRange
* Restore ClosedRange.Index: Hashable conformance
* Move fixed typechecker slowness test for array-of-ranges from slow to fast, yay
* Apply Doug's patch to loosen test to just check for error
Recent changes to contraction of the closure argument/parameter type
variables resulted in speed up in type-checker performance which resolved
one of existing "slow" test-cases.
A type Foo<...>.Bar may only exist conditionally (i.e. constraints on the
generic parameters of Foo), in which case those conditional requirements
should be implied when Foo<...>.Bar is mentioned.
Fixes SR-6850.
Improve situation around closure parameter/argument contractions
by allowing such action if it can be proved that none of the bindings
would result in solver attempting to bind parameter to `inout` type.
Resolves: rdar://problem/36838495
Prior to the following commit, the SILVerifier will assert
on this test case.
PR: 14250 <https://github.com/apple/swift/pull/14250>
commit deebe8b9c7
Author: Andrew Trick <atrick@apple.com>
Date: Mon Jan 29 15:22:28 2018
performTypeChecking: Defer verifyAllLoadedModules in WMO mode.
Since field offsets are now encoded after generic parameters, it
is useful to validate that using generic parameter metadata is now
more resilient in presence of new fields.
* Remove RegisterPreservingCC. It was unused.
* Remove DefaultCC from the runtime. The distinction between C_CC and DefaultCC
was unused and inconsistently applied. Separate C_CC and DefaultCC are
still present in the compiler.
* Remove function pointer indirection from runtime functions except those
that are used by Instruments. The remaining Instruments interface is
expected to change later due to function pointer liability.
* Remove swift_rt_ wrappers. Function pointers are an ABI liability that we
don't want, and there are better ways to get nonlazy binding if we need it.
The fully custom wrappers were only needed for RegisterPreservingCC and
for optimizing the Instruments function pointers.
As a minor step toward more global associated type inference,
allow tentative type witnesses to be found across a protocol
hierarchy, eliminating some recursion through associated type
inference. Fixes a recent regression in validation-test/stdlib/CollectionTypes.swift, as well as rdar://problem/36453271.
If something that we are trying to contextually bind is a nested type inside
protocol or protocol extension, let's try to find the innermost conforming type
from the current declaration context and map Self parameter of the protocol
to that nominal type. Since nested types in protocols aren't yet implemented this
is going to result in failure, but that's better than crashing.
Resolves: rdar://problem/36449760
There was a path through associated type inference where we would end
up recording a type witness that contained an error, but for which we
had not reported that error, which would lead to downstream
crashes. Make sure that we reject such inferences.
And because it triggers once we fix this issue... make sure break
recursion when trying to resolve type witnesses lazily.
Fixes the crash in SR-6609 / rdar://problem/36038033, but we're still
failing to infer in those cases.
Tracked within Apple by <rdar://problem/36754225> Swift CI:
parse_stdlib.sil tests failing with vtable verification. The error is
an assertion failure that we haven't traced back to its cause yet:
Assertion failed: (EntriesSZ == VTableEntryCache.size() && "Cache
size is not equal to true number of VTable entries"), function
verify, file /Users/buildnode/jenkins/workspace/
oss-swift-package-osx/swift/lib/SIL/SILVerifier.cpp, line 4747.
