Dartdoc crashes on "Future<void> foo()"

[whesse]

The Dart language now allows Future<void>, and the type of dart:io RandomAccessFile.close() has been changed to that in commit
44aa9a17fd8ca5278dfe12590ad48212fefda4dd

Future<void> close(); instead of
Future<RandomAccessFile> close();

This causes a crash in line 176 of src/element_type.dart, where f.element.library is tested against null, to special-case A<dynamic>. But with A<void>, f.element is itself null. If we change to f.element?.library != null, we get a crash in the call to ModelElement.from(f.element, lib), again, where there is special casing for dynamic, but not for void.

Flutter code is being changed to use Future<void>, and this IO change should also land, so we need to handle this case.

Reverting 44aa9a17fd8ca5278dfe12590ad48212fefda4dd until this is fixed and rolled to Dart SDK

The builder with the failure is:
https://ci.chromium.org/buildbot/client.dart/dart-sdk-linux-be/19230

@jcollins-g
@jcollins-g: edited to escape types

[jcollins-g]

f.element is null because VoidTypeImpls don't have elements, which is by design. Types without elements aren't known to dartdoc yet and I'll have to wire this in. May take a bit to turn around as there are a lot of assumptions in dartdoc that any type has an element.

[jcollins-g]

Hacking it up so it doesn't crash for Future<void> in this one instance is fairly straightforward. However, the general case of handling void as a type parameter looks to be suprisingly hard. Dartdoc's entire type resolution system assumes that all valid types from the analyzer have non-null elements (and therefore, can have ModelElements associated with them). This will have to be ripped out.

[isoos]

Is there any estimate on the fix (or at least a partial fix)? url_launcher is a popular Flutter package, it would be nice to generate docs for it...

[jcollins-g]

@isoos #1629 should fix those issues and it's just gotten through review. Hopefully I'll be able to test and publish a package with it today, but if not, tomorrow.