I don't want to call this complete until
a) we handle using alias names in switch statements (right now they're
straight-up rejected, not just non-complete), and
b) we prefer non-deprecated names over deprecated ones to be the "real"
enum cases.
but this is a good start, and fixes them showing up poorly in the SDK
analyzer.
rdar://problem/18662118
Swift SVN r27130
This reverts r25401. After reviewing the issues this was intended to solve,
and then talking to Dave, I've decided that this doesn't actually solve
enough of the problems we wanted it to, and it creates added complexity,
so I'm taking it back out.
Originally rdar://problem/19667625.
Swift SVN r25489
This pattern isn't too uncommon:
typedef CF_ENUM(CFIndex, CFFoo) {
CFFooBar
};
typedef NS_ENUM(NSInteger, NSFoo) {
NSFooBar = CFFooBar
};
NSFoo and CFFoo are distinct types, but sometimes you need to convert from
one to the other. Today the only way to do to that is via rawValue, which
is especially unpleasant if the raw types don't match.
This commit introduces a new converting initializer for NSFoo:
init!(_ value: CFFoo) {
self.init(rawValue: RawType(value.rawValue))
}
It's failable by necessity because init(rawValue:) is failable for proper
enums. In practice an audit of our public headers found zero cases where
there are "more" cases in CFFoo than in NSFoo, i.e. cases where the
conversion would fail.
This also applies to option sets and opaque enums, but those use a
non-failable initializer because there's no way to check validity.
rdar://problem/19667625
Swift SVN r25401
The next commit will add tests that mix different kinds of enums and the
division doesn't make too much sense at that point.
No functionality change.
Swift SVN r25400
