Implement exhaustiveness checking in Sema with rich error messages. The
algorithm used is a variant of the one described in Fengyun Liu's paper
"A Generic Algorithm for Checking Exhaustivity of Pattern Matching"
published in the EPFL conference, and Luc Maranget's seminal paper
"Warnings for Pattern Matching"
The Space Engine views pattern matching as a problem of projecting the
scrutinee of a pattern-match into a "Space", then iteratively
constructing a Space from the cases. Taking the difference of this
master space and the covered spaces yields the "holes" left over or
reveals a completely covered space.
The algorithm also extends trivially to redundancy checks in patterns,
but that check is already implemented in SILGen and this algorithm does
not improve upon it.
This is tested in the next commit. This code path is about to
get more cleanup shortly to fix a miscompile with class
existentials (not just subclass existentials; an old problem),
so I'm not too concerned with adding the new conditinals here.
conversions and extend lifetimes over the call.
Apply this logic to string-to-pointer conversions as well as
array-to-pointer conversions.
Fix the AST verifier to not blow up on optional pointer conversions,
and make sure we SILGen them correctly. There's still an AST bug
here, but I'll fix that in a follow-up patch.
When determining whether our inference of an optional type should add
a layer of optionality, look through lvalue types.
Fixes rdar://problem/31779785.
Infer same-type requirements among same-named associated
types/typealiases within inherited protocols. This is more staging; it
doesn't really have teeth until we stop wiring together these types as
part of lookup.
* Allow CodingKey conformance to be automatically derived for enums
which have no raw type (with no associated values) and which have
a raw type of String or Int.
* Allow Encodable and Decodable conformance to be automatically derived
for classes and structs with Encodable/Decodable properties
* Add initial unit tests for verifying derived conformance
My original fix for rdar://problem/31794932 didn't work for generic
functions because it was checking in the unsubstituted interface
type. Check structurally instead. Fixes rdar://problem/31794932.
The throw-checking code wasn't properly coping with functions that
take a single, labeled argument, due to the longstanding lie that
pretends that functions take a tuple argument vs. zero or more
separate arguments. Here, the lie manifests as spurious "call can
throw, but is not marked as such" errors.
Fixes rdar://problem/31794932.
Enums with the ns_error_domain attribute represent codes for NSError,
which means Swift developers will expect to interact with them in
terms of Error. SE-0112 improved bridging for these enums to generate
a struct with the following form:
struct MyError: Error {
@objc enum Code: RawRepresentable {
case outOfMemory
case fileNotFound
}
var userInfo: [NSObject: AnyObject] { get }
static var outOfMemory: Code { get }
static var fileNotFound: Code { get }
}
where MyError.Code corresponds to the original MyError enum defined in
Objective-C. Until recently, both the enum and the synthesized struct
were marked as having the original enum as their "Clang node", but
that leads to problems: the struct isn't really ObjC-compatible, and
the two decls have the same USR. (The latter had already been worked
around.)
This commit changes the struct to be merely considered a synthesized
"external definition", with no associated Clang node. This meant
auditing everywhere that's looking for a Clang node and seeing which
ones applied to external definitions in general.
There is one regression in quality here: the generated struct is no
longer printed as part of the Swift interface for a header file, since
it's not actually a decl with a corresponding Clang node. The previous
change to AST printing mitigates this a little by at least indicating
that the enum has become a nested "Code" type.
In an extension of a nested type, the extended type must be
fully qualified.
Also clean up the diagnostic logic a little bit and centralize
it in diagnoseUnknownType().
Fixes <https://bugs.swift.org/browse/SR-4379>.
Consider the following setup:
struct GenericStruct<T> {
typealias Dependent = T
typealias Concrete = Int
}
We have no way to model 'GenericStruct.Dependent' in the AST, so the
reference would crash. Instead, produce a diagnostic suggesting to
insert generic parameters, like 'GenericStruct<Int>.Dependent'.
The reference 'GenericStruct.Concrete' is fine though, and should
not crash; add a test that it works.
Fixes <https://bugs.swift.org/browse/SR-4390>, <rdar://problem/31480755>.
Previously we prohibited unbound generics in the underlying
type of a typealias, but due to an oversight the check was
not performed when resolving a nested type.
So this worked:
struct Outer { struct Inner<T> {} }
typealias OuterInner = Outer.Inner
let _: OuterInner<Int> = Outer.Inner<Int>()
However it was easy to cause a crash this way by stating an
unbound generic type where one was not expected. Also,
unqualified types in a typealias did not get this treatment,
so the following did not work:
typealias MyOptional = Optional
Formalize the old behavior by allowing unbound generic types
in the underlying type of a typealias, while otherwise
prohibiting unbound references to nested types.
No part of the compiler, including the Clang importer, should
synthesize an attribute that would fail early attribute
validation. When it happens, it would emit diagnostics with no
location information, which is really annoyingly hard to debug.
Instead, assert that this doesn't happen, i.e., both that the Clang
importer doesn't synthesize bogus attributes (as in the previous
commit) and that nothing synthesizes such attributes with empty source
location informations.
In non-asserting builds, just suppress the diagnostic.
Normally name lookup from a where clause walks up to the parent
DeclContext, so it does not need to handle outer generic parameters
specially. But with an extension of a nested type, the outer
DeclContext is the source file, and the extension itself has a
chain of GenericParamLists linked by the OuterParameters field.
When the type checker forms a GenericSignatureBuilder to process
requirements, the GSB may look up concrete conformances. Route such
requests through TypeChecker::conformsToProtocol() so they can be
marked as used. This fixes multi-file scenarios where conformances
from another file might be used only in a generic signature in the
primary file, e.g., rdar://problem/31759258.
When the type checker forms a GenericSignatureBuilder to process
requirements, the GSB may look up concrete conformances. Route such
requests through TypeChecker::conformsToProtocol() so they can be
marked as used. This fixes multi-file scenarios where conformances
from another file might be used only in a generic signature in the
primary file, e.g., rdar://problem/31759258.
We would misreport a cast from G<T> to G<Int> or vice versa
as always failing, because we were checking for an exact
subtype relationship instead of archetype binding.
Fixes <https://bugs.swift.org/browse/SR-3609>.
