When checking whether a particular protocol conformance satisfies all of
the protocol's requirements, we were suppressing substitution failures.
In some cases, this would mean that we marked a conformance "invalid"
without ever emitting a diagnostic, which would lead to downstream crashes.
Instead, treat substitution failures somewhat more lazily. If we encounter
one while performing the checking, put the conformance into a "delayed" list
rather than failing immediately. Teach the top-level type checking
loop to re-check these conformances, emitting a diagnostic if they
fail the second time around.
Fixes rdar://problem/35082483 and likely other issues that slipped
through the type checker or blew up in unpredictable ways.
* Nest various top-level Iterator and Index types, and flatten extensions.
* Fix tests from nesting iterator
* Nest Unsafe*BufferPointer.Iterator, extensionify UnsafeBufferPointer
* Degyb LazyCollection
* Nest Flatten iterator and index
Commit 53754a7a69 added a module pass that serializes the entire module.
Part of that pass is a method called removeSerializedFlagFromAllFunctions that removes the serialized flag from all functions within the module, which allows for more optimizations and for a better dead function elimination.
The problem is that this might break the Devirtualizer: If we run Devirtualization after “SerializeSILPass”, and we do LinkAll after Devirtualizing a function, SIL Verifier will fail: a public_external [serialized] function might be calling a [serialized] function for which we removed the [serialized] flag and added said flag to the module itself.
The verifier thinks that a function_ref inside fragile function is referencing private or hidden symbol.
The general policy has been that even if something crashes at run
time, we don't make it a hard error in Swift 4 mode (or Swift 3 mode!)
if it wasn't a hard error in Swift 4.0 (3.0). In this case, we thought
we could get away with it, and then it turns out it actually caused
some problems. (And as 2bc010681 shows, we can still make mistakes.)
This change isn't perfect because the diagnostic appears in /clients/
rather than in the module that's being compiled as Swift 4 (instead of
Swift 5). But it still means that someone who hasn't changed
/anything/ from a valid Swift 4.0 project will be able to compile
without any changes, even if they were relying on being able to call
+new when -init was unavailable for some reason.
More rdar://problem/35942058
* Eradicate IndexDistance associated type, replacing with Int everywhere
* Consistently use Int for ExistentialCollection’s IndexDistance type.
* Fix test for IndexDistance removal
* Remove a handful of no-longer-needed explicit types
* Add compatibility shims for non-Int index distances
* Test compatibility shim
* Move IndexDistance typealias into the Collection protocol
Follow-up to 49c65facc9 to account for subclasses. An unavailable
-init makes +new unavailable, but reintroducing it in a subclass
should reintroduce +new if the root class is NSObject (where +new is
implemented).
rdar://problem/35914080
This reverts commit 2f80af15ec.
I expected this to have no effect, but it results in one of the
expression type checker tests taking longer, so that test was disabled.
This commit also re-enables the test since it now passes again.
Being part of the type of a private declaration isn't sufficient,
because that could be used for the inferred type of a non-private
variable/constant/property.
Also, introduce a new kind of dependency test that shows both that a
file A changes its interface based on a change in another file B, and
that the swiftdeps output for file A includes the dependency on file B
as cascading.
https://bugs.swift.org/browse/SR-6149
Recent changes have made these tests borderline slow, which means they
no longer fail.
Let's make them really slow instead!
(...since they do not scale well, and we cut the actual testing time off at
1s in the solver, which means really slow isn't going to affect test
time much).
