Instead, just emit a deprecation warning and suggest switching to Optionals.
The old behavior caused several projects to break, so before we change
the behavior here we need to investigate whether we can mitigate most
of those breaks.
Early on in the development of conditional conformances, we put in a bunch
of assertions for code that uses `conformsToProtocol()` but wasn't handling
conditional conformances. Now, `conformsToProtocol()` handles conditional
conformances by default, and these assertions are tripping up code
that would work.
Remove the assertions and add test cases that used to trip up the
assertions (but now work).
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.
Instead of binding collection types directly let's try to
bind using temporary type variables substituted for element
types, that's going to ensure that subtype relationship is
always preserved.
Resolves: rdar://problem/35541153
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
It's probably harmless to record the ones for failures which later cause
us to back out in the solver, but it means we cannot easily set
breakpoints in places like recordFix and stop only in the places where
the fixes actually cause the solution to make progress.
These purportedly mark that we should stop attempting fixes for a given
constraint, but in fact the only code creating these is clearly
unreachable so these serve no purpose.
This allows us to eliminate some special casing around things like
parens, and allows the code to work for other code involving expressions
that are semantically neutral.
Fix collection subtyping relation in function argument position
by emiting special re-abstraction thunk with collection upcast.
Resolves: rdar://problem/35702810
The Codable synthesis code was checking the conditional requirements of
Optional/Array/Set/Dictionary's Codable conformances, which had to be
unconditional. Now that they are properly conditional conformances, we
no longer need the hack.
Thanks to @itaiferber for pointing this out!
Let's not attempt to link arithmetic operators together in
presence of concrete and literal (int, float, string) types.
Resolves: rdar://problem/35740653
Conditional conformances aren't quite ready yet for Swift 4.1, so
introduce the flag `-enable-experimental-conditional-conformances` to
enable conditional conformaces, and an error when one declares a
conditional conformance without specifying the flag.
Add this flag when building the standard library (which will vend
conditional conformances) and to all of the tests that need it.
Fixes rdar://problem/35728337.
While trying to diagnose a problem related to contextual result type
of the trailing closure, don't assume that declaration context is properly
set, instead directly set it to correct one before running type-check.
Resolves: rdar://problem/35699666
For the purposes of partial ordering of declarations (e.g., in
overload resolution), adjust `@autoclosure` parameter types to the
result type of the autoclosure, i.e., the type against which the
argument will be matched. This makes overload resoluton agnostic to
`@autoclosure`.
Fixes SR-6472.
When opening generic types with type parameter requirements,
add information about requirement location to the locator of each
generated constraint to make it easier to extract such information
if needed.
We now store an entire OverloadChoice in the unviable candidates
list (which is used for error recovery), just like we store them
for viable candidates.
The additional information isn't used, so NFC.
in a gross way. Also, handle DeclViaDynamic the same way as DeclViaBridge
and DeclViaUnwrappedOptional.
Also, OverloadChoiceKind says that TupleIndex must be the last entry in the
enum list, so make it the last one (even though this doesn't actually cause
a bug right now).
All this is just cleanup, NFC.
conformsToProtocol() is the main way in which we check whether a given type
conforms to a given protocol. Extend it to check conditional requirements by
default, so that an unmodified caller will get the "does not conform" result
(with diagnostics when a location is present) rather than simply ignoring
the conditional requirements.
Some callers take responsibility for conditional requirements, e.g., to
push them into the constraint system. Allow those callers to opt out of
this checking, and do so wherever appropriate.
Fixes rdar://problem/35518088, where we were ignoring the conditional
requirements needed to verify that Equatable synthesis could be performed.
Using this constraint locator element, we can check when a failed
constraint is due to an unsatisfied conditional requirement of a
protocol conformance. Unfortunately, it's hard to turn this into
an actionable diagnostic right now.
