Filter out more spurious Promise-related type checking errors.

Filter out more spurious Promise-related type checking errors.

- Expand the PromiseErrorFilter to allow multiple types of errors to be filtered out.

- Add a new type of allowed error, namely errors from the compiler failing to
  unwrap the result of a returned Promise chain.  Example:

  /** @return {!Promise<string>} */
  var getStringAsync = function() {
    /** @return {!Promise<string>} */
    var generateString = function() {return Promise.resolve('foo');};
    return Promise.resolve().then(generateString);
  };

  The compiler will emit an error that looks like

  ERROR - inconsistent return type
  found   : Promise<Promise<string>>
  required: Promise<string>

BUG=406995
Committed: https://crrev.com/e24723c00ae1257c67a47c5d48c3a4ad7a8e30f5
Cr-Commit-Position: refs/heads/master@{#307045}

[Ben Kwa, 2014-12-04 18:51:52]

kenobi@chromium.org changed reviewers:
+ fukino@chromium.org

[fukino, 2014-12-05 04:53:50]

I'm anxious about if we can filter out unwrapping-promise errors one by one, but
this change itself lgtm with nits.

https://codereview.chromium.org/776273003/diff/20001/third_party/closure_comp...
File third_party/closure_compiler/error_filter.py (right):

https://codereview.chromium.org/776273003/diff/20001/third_party/closure_comp...
third_party/closure_compiler/error_filter.py:25: 
nit: Two blank lines needed between top-level definitions.

https://codereview.chromium.org/776273003/diff/20001/third_party/closure_comp...
third_party/closure_compiler/error_filter.py:55: return any([msg.match(error)
for msg in self._allowed_error_patterns]);
nit: 'pattern' or 'error_pattern' instead of 'msg' sounds better to me, because
we use 'msg' in different meaning in the error itself.

https://codereview.chromium.org/776273003/diff/20001/third_party/closure_comp...
third_party/closure_compiler/error_filter.py:56: 
nit: Two blank lines needed between top-level definitions.

[Ben Kwa, 2014-12-05 17:30:28]

Done.  Thanks!

Regarding your reservations about the unscalability of this approach, I agree. 
But, I think this CL positions us better to cope with (what I think will be
infrequent) new occurrences of this problem.  I think this can tide us over till
a real solution is reached.

https://codereview.chromium.org/776273003/diff/20001/third_party/closure_comp...
File third_party/closure_compiler/error_filter.py (right):

https://codereview.chromium.org/776273003/diff/20001/third_party/closure_comp...
third_party/closure_compiler/error_filter.py:25: 
On 2014/12/05 04:53:50, fukino wrote:
> nit: Two blank lines needed between top-level definitions.

Done.

https://codereview.chromium.org/776273003/diff/20001/third_party/closure_comp...
third_party/closure_compiler/error_filter.py:56: 
On 2014/12/05 04:53:50, fukino wrote:
> nit: Two blank lines needed between top-level definitions.

Done.

[Ben Kwa, 2014-12-05 17:31:56]

The CQ bit was checked by kenobi@chromium.org

[commit-bot: I haz the power, 2014-12-05 17:32:36]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/776273003/40001

[commit-bot: I haz the power, 2014-12-05 18:09:32]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2014-12-05 18:10:24]

Patchset 3 (id:??) landed as
https://crrev.com/e24723c00ae1257c67a47c5d48c3a4ad7a8e30f5
Cr-Commit-Position: refs/heads/master@{#307045}