Change all remaining tests to use associatedtype instead of typealias in protocols

[gregomni]

Split parsing for typealias & associatedtype, allow typealias in protocol, but not as a constraint in generics.

First step in getting real type aliases in protocols is to finish smoking out the ones that ought to be associated types. Cleaned up parsing of the two, including dropping a now unneeded ParseDeclOptions flag, made typealias in a protocol an error for the moment, and then converted all the places in the tests that didn’t care about it being a deprecation warning before but do care now.

Then made typealias in a protocol actually valid, which works great except that you can't use them in where clauses in generics. So added new diagnosis if you attempt to use a protocol’s typealias in a where clause, suggesting an associatedtype instead.

[gregomni]

I've backed off from trying to make type aliases inside protocols work in generic where clauses right away - it was taking longer than I thought it would, and this much of the work is separable and seems better as an individual pull anyway.

As an interim step, type aliases are now allowed inside protocols, we produce a specific diagnosis if you try to use them as if they were an associatedtype in a where clause, but otherwise they act like you would hope for protocol conformance purposes (i.e. as an alias, not as another hidden generic param).

@lattner I ended up in a merge conflict with your generic type aliases work. I think the resolution was fairly straightforward, but it'd be great if you could review the ParseDecl.cpp and test/decl/typealias/typealias.swift changes here when you have the time.

[lattner]

Oh, sorry about that, I'll take a look when I get a chance.

Unrelatedly, @DougGregor and I were discussing this briefly, in terms of how to land this in Swift 3. IIRC, he had some concerns about how this lands - we want to make sure that people who ignore the "deprecated" warnings in Swift 2 get an acceptable upgrade experience in Swift 3. Doug, do you have any specific guidance here?

[gregomni]

@lattner No problem! Conflicts Happen.

The current behavior if you've ignored the deprecation warnings is that:

• typealias A will complain that there is a missing = (assigning a type to the alias is required now, not optional). Maybe this ought to still have a better 'you probably meant associatedtype' diagnosis.
• typealias A = Int will silently work for any type whose conformance actually uses Int (is this a problem? Not sure), and will fail with reasonable diagnoses if not (e.g. "protocol requires property 'foo' with type 'A' (aka 'Int')")

[gribozavr]

Could you split test updates (typealias => associatedtype) into a separate PR? We could merge that immediately.

[gregomni]

@gribozavr Good idea. Just did that here, all tests pass locally. You want to kick off a ci test, or shall I go ahead and just merge?

I'll re-add the actual feature changes in a separate pull request.

[gribozavr]

@swift-ci Please test

[gribozavr]

@gregomni Thank you! Could you also retitle the PR?

[gribozavr]

@gregomni Feel free to merge when tests pass, thank you!

[gregomni]

@gribozavr Done, and will do!