This presents a regression in diagnostic quality that is definitely
worth it not to lie to SILGen about whether a switch is covered or not.
At the same time, disable SIL’s unreachable diagnostic for ‘default’
clauses which would previously cause a warning to be emitted if the
default was proven to be unreachable. This analysis is incomplete
anyways and can be done by Sema in the future if we desire.
The Space Engine includes a heuristic that attempted a combinatorics-
based check to see if a pattern covered an insufficient amount of cases.
In straight-line switches this avoided computing a subspace match that
would have been quite expensive computationally. However, when
expressive patterns (like tuple patterns) are used, it can fool the
check because the covered space is much larger than the actual size of
the space due to pattern overlap that counting like this simply can't detect.
Instead, just do the right thing and perform a space subtraction after
the existing preconditions for the heuristic are satisfied.
Resolves SR-6316
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.
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.
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.
For Swift 3 / 4:
Deprecate the spelling "ImplicitlyUnwrappedOptional", emitting a warning
and suggesting "!" in places where they are allowed according to
SE-0054.
In places where SE-0054 disallowed IUOs but we continued to accept them
in previous compilers, emit a warning suggesting "Optional" or "?" as
an alternative depending on context and treat the IUO as an Optional,
noting this in the diagnostic.
For Swift 5:
Treat "ImplicitlyUnwrappedOptional" as an error, suggesting
"!" in places where they are allowed by SE-0054.
In places where SE-0054 disallowed IUOs, emit an error suggestion
"Optional" or "?" as an alternative depending on context.
The previous code was too clever in trying to avoid work and missed
the fact that ClassDecl::getSuperclass produces an interface type but
the types in the inheritance clause are contextual types.
This actually successfully built:
- in non-WMO builds with a public subclass and an internal base class,
because the internal class symbol wouldn't get stripped out.
- in WMO builds with an internal subclass and a private base class,
because 'private' has no distinction at the linkage level for a WMO
build.
However, it's highly likely that trying to import a library containing
such types would result in instability (read: compiler and debugger
crashes), and it's clearly a mistake to allow this. (If you can't show
your superclass to a user in a library's generated interface,
something's definitely gone wrong.)
https://bugs.swift.org/browse/SR-6206
Fix a couple more places where we should not allow IUOs and add
additional tests for these as well as parallel tests for the long
spelling ImplicitlyUnwrappedOptional.
We were allowing them in parens in some contexts, but shouldn't have.
Also added tests for function types and tuple return types to ensure
we're not allowing them in these places.
SE-0054 specified that the use of implicitly unwrapped optionals was
limited to just a few places, but the implementation at the time did not
completely ban the other uses. This is another attempt to do so, but
it's only on for compilations in Swift 5 mode and later.
For earlier versions, we fall back on the existing implementation.
Fixes: rdar://problem/27707015
Per SE-0054, implicitly unwrapped optional is not a distinct type in the
type system, but rather just the notion that certain Optionals (denoted
by the sigil "!" rather than "?") can be implicitly unwrapped.
This is a first step in the direction of implementing this notion by
emitting a warning if the type is spelled out.
subscript is on the destination side of an assignment and restricting matching
overload candidates to only the set-able members.
Also, if we are left with a single candidate, we can recheck unresolved index
expressions with better parameter info.
Currently edge related to the parameter bindings is contracted
without properly checking if newly created equivalence class has
the same inout & l-value requirements. This patch improves the
situation by disallowing contraction of the edges related to parameter
binding constraint where left-hand side has `inout` attribute set.
Such guarantees that parameter can get `inout` type assigned when
argument gets `l-value` type.
Resolves: rdar://problem/33429010
