change includes both the necessary protocol updates and the deprecation
warnings
suitable for migration. A future patch will remove the renamings and
make this
a hard error.
The original bug here about not serializing base protocol conformances
is unlikely to return, but I think this still captures the spirit of
the original test: rely on a base protocol conformance without the
model type ever referring to it.
rdar://problem/25125727
I can't get this to reproduce with anything more self-contained,
unfortunately: it seems that IntegerLiteralConvertible is the interesting
protocol, and the type has to come from the standard library.
Swift SVN r25294
...rather than trying to serialize them again, which could lead to attempting
to cross-reference an ExtensionDecl, which can't be done.
rdar://problem/19794141
Swift SVN r25292
Mechanically add "Type" to the end of any protocol names that don't end
in "Type," "ible," or "able." Also, drop "Type" from the end of any
associated type names, except for those of the *LiteralConvertible
protocols.
There are obvious improvements to make in some of these names, which can
be handled with separate commits.
Fixes <rdar://problem/17165920> Protocols `Integer` etc should get
uglier names.
Swift SVN r19883
In most cases this means adding @public to things that get serialized;
in a few cases it means using a modern public stdlib API instead of
a legacy thing I was trying to keep @internal.
Swift SVN r19350
That is, if we need a type MyIndex<T> to be a valid ForwardIndex, we should
be able to find it in the conformance for BidirectionalIndex, which inherits
from ForwardIndex.
<rdar://problem/15484898>
Swift SVN r11270
