Remove comment-based syntax for generic methods

[munificent]

We currently support and in some places still use the transitional /*<T>*/ syntax for generic methods. Now that real syntax is supported, we should phase out and then eliminate the old syntax.

I can file tracking bugs for the sub-issues if people want, but, for now, here's the known subtasks:

• Add a deprecation notice when the old syntax is detected. (Do we need to do this?)
• Remove uses of the syntax in our core libraries.
• Remove uses of the syntax in other packages and applications we maintain.
• Remove support in analyzer for parsing the comments and treating them as annotations.

Currently, there are a few places where we still deliberately use the old syntax:

• The LineSplitter class behaves differently depending on if you enable strong mode or not.
• Some 'as' checks are marked as as Object /*=ConcreteClass*/ for performance reasons because implementations do not currently take advantage of strong mode.

We'll want to ensure those are addressed first before the syntax is removed.

[bwilkerson]

We should also remove uses in our own code before removing support from analyzer.

[munificent]

Yes! I didn't intend that to be an ordered list, but I can see how it looks like it. Re-ordered. :)

[srawlins]

That LineSplitter behavior you note, is there an issue for that?

No, I didn't file a tracking issue, and Florian hasn't either. I can when we get closer to working on it.

Is it an issue?

Yes, but @floitschG knows better than I do. I believe the issue is that the existing API is basically un-statically-typeable. It claims to be of a type that either it isn't, or that can't be expressed. I don't recall the details.

Changing it to something that makes sense in strong mode would be a breaking change, so instead, it uses /*<T>*/ syntax to have a different type in strong mode than it does in spec mode.

[anders-sandholm]

At least the "Add a deprecation notice when the old syntax is detected" part should be 1.23.
No?

[dgrove]

Is this actually happening for 1.23? I don't think there are open tasks for, say, the analyzer for 1.23.

[leafpetersen]

@floitschG how close are we to eliminating this from the core libraries?

@srawlins Is internal code in a good state with respect to this yet?

@kevmoo Do we have a plan for external packages?

[kevmoo]

@leafpetersen I'd LOVE if we had a milestone w/ a hint/lint that told folks if they have these anywhere and help folks migrate.

@bwilkerson @pq – possible?