Skip to content

dartanalyzer does not honor generic methods in strong mode without seemingly superfluous 'await' #26931

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
trinarytree opened this issue Jul 21, 2016 · 2 comments
Labels
closed-duplicate Closed in favor of an existing report legacy-area-analyzer Use area-devexp instead. P1 A high priority bug; for example, a single project is unusable or has many test failures type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)

Comments

@trinarytree
Copy link

Use dartanalyzer --strong on the following

var confuse;
Future/*<T>*/ genericMethod/*<T>*/() async => confuse as dynamic/*=T*/;

Future<int> hasNoError() async => await genericMethod();  // Apparently this is ok.
Future<int> hasError() async => genericMethod();  // "Unsound implicit
  // cast from Future<dynamic> to Future<int>"
  // Wtf?  Just because I didn't add the superfluous 'await'?
@bwilkerson bwilkerson added P1 A high priority bug; for example, a single project is unusable or has many test failures legacy-area-analyzer Use area-devexp instead. analyzer-strong-mode type-bug Incorrect behavior (everything from a crash to more subtle misbehavior) labels Jul 21, 2016
@bwilkerson
Copy link
Member

@leafpetersen @jmesserly

@jmesserly
Copy link

Hi @trinarytree -- what is going on here is type inference couldn't figure this one out. Type inference is not perfect for Future because Future often implies a Future<T> | T union type, and we have no way of writing that in Dart. So the current inference system makes an arbitrary choice.

You can fix your code like this:

Future<int> hasError() async => genericMethod/*<int>*/();

in other words, explicitly pass the type argument, that way you don't have to rely on type inference.

There's two bugs currently assigned to me to fix inference: #25322 and #25944. I have a CL that actually does fix them, by introducing that union type as part of the type inference system. Unfortunately I haven't finished the CL yet. It needs a lot of care to make sure those union types don't escape outside the inference, as the boundary is not very clear right now in Analyzer.

I will try to get to this soon, but to keep our tracking simple, I'm going to mark this duplicate of #25322. I'll CC you over there.

@jmesserly jmesserly added the closed-duplicate Closed in favor of an existing report label Jul 21, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed-duplicate Closed in favor of an existing report legacy-area-analyzer Use area-devexp instead. P1 A high priority bug; for example, a single project is unusable or has many test failures type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)
Projects
None yet
Development

No branches or pull requests

3 participants