Allow (or always) prefix for dart:core elements

[srawlins]

I am encountering code in mockito, generating code which includes a class which implements a method called List. I think this is a method defined in proto-generated services. In any case, when mockito generates this code, we get an error for other code which refers to the type, List:

78: List<String> get idFields => List isn't a type.

Boo. The only way to get around this is to import core with a prefix, import 'dart:core' as core; or whatever.

I think this would make most code, er... very hard to read. But I'd also love this option for mockito 😄 .

[natebosch]

I'm not sure if it is feasible for us to handle this automatically. We can't tell if a refer('List') is intended to refer to dart:core, or something local to the library being generated.

I think we might need to use refer('List', 'dart:core') in mockito.

[srawlins]

I think we might need to use refer('List', 'dart:core') in mockito.

I think we do, here (approximately, we build a TypeReference manually).

I think the comment here and the code here indicate that dart:core will never be prefixed.

[natebosch]

Thanks! I think an option to keep prefixes for dart:core makes sense.

[srawlins]

I wish I could even hack around _doNotPrefix, like maybe say refer('List', 'dArT : core ') or something. 😏

But it would be a big ole breaking change to always prefix. E.g. in mockito we have code like refer('Invocation') assuming it is imported without a prefix. I imagine there is a ton of code out there like that.

We could deal with that by adding an option on DartEmitter, like prefixCore or something.

[natebosch]

We could deal with that by adding an option on DartEmitter, like prefixCore or something.

SGTM.

assuming it is imported without a prefix.

We could either try to clean all of those up, or we could add an unprefixed import of dart:core to catch the straggling references.