3

I use Closure Compiler on my sources and recently decided to enable the most strict mode via --jscomp_warning=reportUnknownTypes. Alas, it triggered a lot of warnings inside the goog.base itself! I've fixed all the problems in my own code and now I'm looking for a way to silence/remove errors in the closure library code.

I tried to fix errors in base.js but quickly realized it's unfeasible. There are approximately 108 errors in the file and in most cases they are real errors because of goog.base doesn't care much about types: it's a common practice there to define a type like {?} or {*}.

I also tried to use --warnings_whitelist_file to silence warnings I don't care about but it didn't work either. For an error:

..\js\google\base.js:204: WARNING - could not determine the type of this expression cur[part] = opt_object; ^

I tried different forms in the whitelist file but none has worked:

..\\js\\google\\base.js:204 could not determine the type of this expression ..\\js\\google\\base.js:204 WARNING - could not determine the type of this expression ..\js\google\base.js:204 could not determine the type of this expression ..\js\google\base.js:204 WARNING - could not determine the type of this expression ../js/google/base.js:204 could not determine the type of this expression ../js/google/base.js:204 WARNING - could not determine the type of this expression ..\js\google\base.js:204 WARNING - could not determine the type of this expression cur[part] = opt_object;

Does anybody have a working solution to have this mode enabled and not get spammed by the errors from the closure library itself?

I use latest Closure Compiler which is: Version: v20150315 Built on: 2015/03/17 14:18

alex
  • 479,566
  • 201
  • 878
  • 984
real4x
  • 1,433
  • 12
  • 11
  • 1
    `reportUnknownTypes` is quite spammy and not generally recommended. Someday we'll get around to https://github.com/google/closure-compiler/issues/152 (implementing a more nuanced version of that check) which we may recommend turning on. – Tyler Apr 09 '15 at 06:08
  • Well, it is spammy but once I got all my errors fixed (sometimes with a hack, though) the code became much more correct. Several unnoticed bugs were fixed. So, in spite of all the troubles it's a very useful mode which I'd like to continue using. – real4x Apr 09 '15 at 09:01
  • Btw, I'm "ihsoft" on githab :) Recent bug to the compiler was from me. – real4x Apr 09 '15 at 09:05
  • 1
    If you use the Java API to run the compiler it is possible to configure a warning guard to not show the warnings. It should also be noted that while the type values are not know, they are expected to be unknown, a better check would not warning about value declared to be unknown. There is a more limited but still very useful checks that are part of the conformance framework (a unknown this check and unknown class property check) – John Apr 10 '15 at 04:29

1 Answers1

2

So, I decided to go the path with silencing warnings in the base.js. For that I've investigated compiler sources (thanks to the authors it's open source) and I found out that flag description doesn't match its actual effect. The description says:

A file containing warnings to suppress. Each line should be of the form <file-name>:<line-number>? <warning-description>

But in fact this guard intercepts matching errors and converts them into warnings. Moreover, line numbers are completely ignored. I see no use of this flag with such behavior but I bet authors had a good reason to implement it this way.

Anyways, I forked from the main branch and fixed flag's behavior. Now matched errors and warnings are actually suppressed (silenced). Line numbers are now considered in the matching.

Syntax of the whitelist file is very similar to the error/warning output. For example if you get error (or warning) like this:

..\js\google\base.js:120: ERROR - could not determine the type of this expression if (goog.getObjectByName(namespace)) { ^

Then the relevant record in the whitelist file will be:

..\js\google\base.js:120 could not determine the type of this expression

You may add content of multiline errors as comments preceding them with # but only first line will be used for matching.

If this is what you need you may obtain the binary via one of the two ways:

real4x
  • 1,433
  • 12
  • 11