Please provide a way to suppress Bounded generic semantics are currently still in development warnings from closure-make-deps

[cpcallen]

Declarations like @template {ClassName} C in the input to closure-make-deps provoke warnings like:

WARNING in /.../file.js at 38, 3: Bounded generic semantics are currently still in development

Is there a way to suppress these warnings? If not, could one be added? I am happy to get warnings from the compiler about them (where I can suppress if desired), but I don't see why make-deps should care.

[12wrigja]

Slightly unrelated to your ask, but I saw this error message the other day and realized it was because I had the wrong syntax for @template: it should not have {}. E.g:

closure-library/closure/goog/dom/dom.js

Line 182 in ba7c8d7

* @template T

[cpcallen]

Slightly unrelated to your ask, but I saw this error message the other day and realized it was because I had the wrong syntax for @template: it should not have {}.

True, and one solution would be to remove the bounds added by a colleague, but as we are busy porting to TypeScript which does support bounded generics it would be preferable not to lose this information in the mean time, and since the compiler already supports bounds to the extend of generating a warning about them and then ignoring them, it would be nice if we could just suppress the warning.

[12wrigja]

I think this would entail some changes here:

closure-library/closure-deps/lib/parser.js

Line 255 in 5f0d878

errors.push(new ParseError(fatal, message, sourceName, line, lineOffset));

which I think is where errors are bubbled up from running the jsfile_parser (which isn't owned by closure-library owners).

[shicks]

Given that Closure Compiler does not actually treat the bounds correctly, if you're dead-set on retaining this information, you're probably better off doing so in a non-annotation comment. But I don't really understand quite what you're actually doing here - I assume you're migrating from JS to TS, but in that case, where are these bounds coming from? Are you trying to add them before actually cutting over to TS?

Anyway, the error is there for a reason: the feature doesn't work, so we're not going to add an option to suppress it.

[cpcallen]

I assume you're migrating from JS to TS, but in that case, where are these bounds coming from?

A colleague added them. It is possible that they are more familiar with JSDoc as understood by tsc than they are the Closure type system.

Are you trying to add them before actually cutting over to TS?

My thought was that it would be useful to keep this information in a form that some of the tooling we use (e.g. VisualStudio) understands, so that it might get transcribed automatically when we do the cut over.

Anyway, the error is there for a reason: the feature doesn't work, so we're not going to add an option to suppress it.

That is a reasonable conclusion to this issue—though I note that I like the approach that Closure Compiler takes, where almost all the diagnostics can be made to be errors, non-fatal warnings, or suppressed entirely. (Though perhaps that is more complexity than is justified here.)

[shicks]

Are you saying that the compiler already allows you to suppress this one? I find that surprising - I was under the impression that it was unsuppressible.

I think the fact that Closure and TypeScript interpret it differently is likely to cause you to have a bad time.