A lint tool for javascript.

Adds Linter.java and a build rule that runs sanity checks on our
client-side JS.

The linter looks for @requires, @provides, and @overrides comment
annotations in each JS file and comes up with a set of globals that
the file is allowed to read/write.

It then applies a ScopeAnalyzer to map nodes to the scopes that
contain them.  The ScopeAnalyzer has a few overrideable methods,
and so can support a wide variety of scoping models including
  (1) ES3.1 scoping rules plus let and const
  (2) ES3 scoping
  (3) ES3 scoping with IE quirks
  (4) Block scoping as understood by the naive JS programmer.

The scoping rules used by Linter are javascript standard, with one
added constraint.
Variables may not be re-declared, unless all re-declarations occur in
mutually-disjoint loops.  This catches errors like
  var i = 1;
  if (...) {
    ...
           for (var i = 0; ... )  // Deeply nested loop
    ...
  }
  return i;
but allows the common idiom whereby loop iterators are reused within a loop
  for (var i = 0; ...) { ... }
  for (var i = 0; ...) { ... }
This works because the below is banned
  for (var i = 0; ...) { .. .}
  return i;
since a variable declared in a loop can only be used in the loop.

Once scopes are assigned, a VariableLiveness instance walks the
tree figuring out the conservative set of variables which might
be live at any point in the program.

The scoping and liveness data is used to check for common scoping
and namespace violation bugs.

The Linter also identifies expressions that are typically used as
expressions but which appear in a statement context.

So
  {
    a;
    +b;
  }
is flagged because the operator + is normally evaluated for its value,
but the value is ignored in this case.

I included &&, ||, and ?: in the set of expressions typically
evaluated for their value.
So
  condition && side_effecting_expression();
should instead be written as
  if (condition) { side_effecting_expression(); }

This change also includes cleanup and fixes of our supporting JS
to make it lint clean, and adds an ANT build rule that runs the
linter over our supporting JS when tests are built.


Submitted @3808

[MikeSamuel, 2008-12-30 09:42:05]

I discuss the reasons for the various warnings at
http://groups.google.com/group/google-caja-discuss/web/lint-logs.html with a
breakdown of example runs over the prototype, caja, and jquery codebases.

A good way to start this review is by looking at the header comments for
ExitModes and VariableLiveness, and then the testcases in LinterTest,
VariableLivenessTest, and ExitModesTest.

Then try looking at ScopeAnalyzer, Linter, VariableLiveness, and ExitModes in
that order.

[MikeSamuel, 2009-10-19 23:49:39]

Please look at the build.xml and other non ancillary file changes.

[metaweta, 2009-10-20 00:10:01]

LGTM

[metaweta, 2009-10-20 00:10:24]

http://codereview.appspot.com/9674/diff/59239/60205
File src/com/google/caja/tools/GenRuleAntTask.java (right):

http://codereview.appspot.com/9674/diff/59239/60205#newcode33
Line 33: private boolean unless = false;
Unless what?  This seems strange to me.

[MikeSamuel, 2009-10-20 00:13:26]

http://codereview.appspot.com/9674/diff/59239/60205
File src/com/google/caja/tools/GenRuleAntTask.java (right):

http://codereview.appspot.com/9674/diff/59239/60205#newcode33
Line 33: private boolean unless = false;
On 2009/10/20 00:10:24, metaweta wrote:
> Unless what?  This seems strange to me.

See the unless="" attribute in build.xml at line 526