Analyzer complains about error in comment

[zoechi]

class EventBus {
  EventData fire(EventType /*<T>*/ eventType, /*<T>*/ EventData data) {
    ...
  }
}

Warning:(35, 31) The name 'T' is not a type and cannot be used as a parameterized type

I saw some code reviews where Dart team members added such comments for future generic method support, but I didn't expect this to have any effect yet.

I copied the code above from some other project and didn't bother to remove the comments and now get warnings.
Is this related to strong mode or default analyzer?

[zoechi]

Dart VM version: 1.14.0-edge.a689bf41805c251b5bae646e0eb82f832d1e309f (Wed Nov 18 17:36:06 2015) on "linux_x64"

[bwilkerson]

@zoechi This should only show up in strong mode, but it seems wrong to produce an error for code that is perfectly valid. Are you running with strong mode enabled?

@jmesserly Should we change this feature so that if the comments don't parse correctly we just silently ignore them? Or perhaps the errors should be behind a separate flag, especially given that this is a short-term work-around until we can get the generic method DEP approved.

[zoechi]

Yup, I have strong-mode enabled.

I started working on porting a Polymer 0.16 project to 1.0.0-rc.x and got a warning I had no idea where it came from.
Now with strong-mode, linter included in analyzer, experimental features, it's really hard to figure out what produces the hint/error/warning.

I'm fine with comments that have a meaning, they also can produce warnings. I like to get as much tooling support as possible.
I just really would love to get proper information what produced the warning. See also #57248
I think each warning/hint/info should contain an exact key that allows to look up where exactly it comes from like

Warning:(35, 31) The name 'T' is not a type and cannot be used as a parameterized type [SM123]

for strong mode error code 123 and a const someError = 123; somewhere in the GitHub repo containing the strong mode plugin source.

The linter seems to at least add [lint] somewhere (see also #57248), but no exact key.

The messages are sometimes really hard to tell apart. An exact key would make this much easier.

[bwilkerson]

I agree. We need error codes to make it easier (possible?) to find documentation for them.

I'm not sure why it matters where the error comes from, though. As long as the documentation said something like:

This warning is produced only when strong mode is enabled.

My concern is more about false positives, but perhaps that not a big concern, given that you're trying to document that you'd be using generic method syntax if it were available.

By the way, I think the following will let strong mode do what you want:

EventData fire/*<T>*/(EventType /*<T>*/ eventType, EventData /*=T*/ data) {
  ...
}

Note, however, that support for this form is short-term and will be removed without notice.

[jmesserly]

@jmesserly Should we change this feature so that if the comments don't parse correctly we just silently ignore them? Or perhaps the errors should be behind a separate flag, especially given that this is a short-term work-around until we can get the generic method DEP approved.

The problem here is it does parse correctly. It parses to EventType<T>, which is then an error because T is not a type.

I don't see how we can hide this message in the current design for the comments.

My original preference was to have it work quite differently. I wanted to support syntax like:

/*T*/ foo/*<T>*/(/*T*/ t);

Then, the comments would be totally ignored in the scanner/parser. They would only kick in during name binding, if and only if the type name matches one that is declared in a comment.

I believe that would give the desired error suppression behavior, as well as allow cleaner syntax (/*T*/ instead of /*=T*/).

[bwilkerson]

Would it support adding type parameters, such as (List /*<T>*/ list)?

[jmesserly]

@zoechi -- for better or worse:

• we need generic methods to make strong mode work,
• we have to encode generic methods in comments.

As a consequence, comments will become meaningful to --strong mode, at least in some cases.

That said, we can fix this case, but it does require completely reimplementing at what point we find the comments. (all of the scanner/parser code needs to be removed, instead we look for them later)

[jmesserly]

And I'm happy to fix this, thanks @bwilkerson for sending it my way! Let me know if the approach sounds right (revert scanner/parser changes, instead look for the comments later on, IFF we are in a generic function/method only -- which the example in this bug would not be, so we shouldn't even look for them)

[jmesserly]

Addendum: and thanks @zoechi for trying --strong and catching this! This kind of usability feedback is incredibly valuable.

[jmesserly]

Would it support adding type parameters, such as (List /*<T>*/ list)?

yup, I think so. I'd have to look in depth because it's a complete reimplementation. But basically we would have a notion that we have a type parameter T in scope, so we'd look for /*<T>*/ comment in visitTypeName (of TypeResolverVisitor?) ... we could delay parsing until that point. Unless both parsing and name resolution succeeds, ignore it.

[jmesserly]

(essentially, about every place in parser where we currently parse generic comments, we'd instead leave them unparsed and move the "search for a comment" to resolver.dart ... that lets us confirm that the syntax as well as the name resolution works before we accept it.)