Fix void as a type parameter by rewriting most of element_type.dart

[jcollins-g]

Fixes #1625. As mentioned in that bug, the amount of "if (type) do_thing;" spread throughout ElementType (not to mention the different meanings of its methods in different contexts) was making it too hard to rationalize about the intended behavior to try to extend it again for void as a type parameter.

Instead, I've refactored and split ElementType into a set of subclasses and got almost all the if type stuff moved into a factory constructor. This should result in more-or-less identical behavior to the old version, except now, Future<void> and anything else with a void type parameter should function correctly. The subclasses are roughly paralleling the class structure of DartType in the analyzer near the root, with changes appropriate to dartdoc's needs. It's not perfect, but perfect is the enemy of good and I wanted to get this out as quickly as I could.

One minor behavior change is that code that didn't specify a type at all for something where there's no type inference will be documented as "dynamic" rather than having no listed type.

[devoncarew]

Is this ready for review?

[jcollins-g]

I think it's ready for a start. There's a niggling regression on Flutter I haven't quite ironed out yet.

[jcollins-g]

This should be ready for a serious look now. Added @bwilkerson in case he'd like to comment on the new object model. Definitely open to suggestions though I might defer some of them; I sadly had to do this redesign in a hurry for the P0.

[jcollins-g]

@kevmoo I'd like your input on the impact of sprinkling dynamic in more places; specifically, in (non-type) parameters. It's particularly noticeable in operator== inherited from Object.

I introduced it by accident in the element_type rewrite and I can find a way to get rid of that, but I actually find the docs more readable this way. It's clear then that this is a dynamic parameter rather than some other inferred type (which if you're looking at the code it can sometimes be hard to tell).

[kevmoo]

I think it's okay...do you have other examples?

[jcollins-g]

@kevmoo:

We now show it as a return-type from a function parameter (edited to have correct screenshot)

And, as a type for a parameter to an optional function parameter:

[kevmoo]

I think it's okay. Run with it and get feedback?

…

On Mon, Mar 12, 2018 at 11:30 AM, jcollins-g ***@***.***> wrote: @kevmoo <https://github.com/kevmoo>: We now show it as a return-type from a function parameter: [image: screenshot from 2018-03-12 10-59-08] <https://user-images.githubusercontent.com/14116827/37302137-ea85bb96-25e7-11e8-8206-43b21135d5e7.png> And, as a type for a parameter to an optional function parameter: [image: screenshot from 2018-03-12 11-28-26] <https://user-images.githubusercontent.com/14116827/37302384-94df56ec-25e8-11e8-9a98-0a7ba2fb9763.png> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1629 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABCislju06pbq_0HoFhnFZxtja5TNKpks5tdr7HgaJpZM4SjdXK> .

[jcollins-g]

will do :-)