Compiler thinks nested function parameter is undefined in ECMASCRIPT6_TYPED mode

[jart]

I'm using v20160315 and I'm noticing the following error when I compile Closure Library code in ADVANCED ECMASCRIPT6_TYPED mode:

external/closure_library/closure/goog/iter/iter.js:1236: ERROR - variable index is undeclared
  function getIndexFromElements(index) { return elements[index]; }
                                                         ^

external/closure_library/closure/goog/iter/iter.js:1280: ERROR - variable getIndexFromElements is undeclared
        (sortedIndexIterator.next()), getIndexFromElements);
                                      ^

2 error(s), 0 warning(s)

The params I'm using are:

--js_output_file=bazel-out/local-fastbuild/bin/closure/testing/test/arithmetic_module_test_bin.js
--create_source_map=bazel-out/local-fastbuild/bin/closure/testing/test/arithmetic_module_test_bin.js.map
--language_in=ECMASCRIPT6_TYPED
--language_out=ECMASCRIPT3
--compilation_level=ADVANCED
--dependency_mode=LOOSE
--warning_level=VERBOSE
--generate_exports
--js_module_root=bazel-out/local-fastbuild/bin
--source_map_location_mapping=bazel-out/local-fastbuild/bin|
--source_map_location_mapping=|/
--hide_warnings_for=.soy.js
--hide_warnings_for=external/closure_library/
--hide_warnings_for=external/soyutils_usegoog/
--formatting=PRETTY_PRINT
--debug
--entry_point=goog:arithmetic_module_test
--js=external/closure_library/closure/goog/base.js
--js=external/closure_library/closure/goog/a11y/aria/announcer.js
...

The code in question is:

/**
 * Creates an iterator that returns combinations of elements from
 * {@code iterable}.
 *
 * Combinations are obtained by taking the {@see goog.iter#permutations} of
 * {@code iterable} and filtering those whose elements appear in the order they
 * are encountered in {@code iterable}. For example, the 3-length combinations
 * of {@code [0,1,2,3]} are {@code [[0,1,2], [0,1,3], [0,2,3], [1,2,3]]}.
 * @see http://docs.python.org/2/library/itertools.html#itertools.combinations
 * @param {!goog.iter.Iterator<VALUE>|!goog.iter.Iterable} iterable The
 *     iterable from which to generate combinations.
 * @param {number} length The length of each combination.
 * @return {!goog.iter.Iterator<!Array<VALUE>>} A new iterator containing
 *     combinations from the {@code iterable}.
 * @template VALUE
 */
goog.iter.combinations = function(iterable, length) {
  var elements = goog.iter.toArray(iterable);
  var indexes = goog.iter.range(elements.length);
  var indexIterator = goog.iter.permutations(indexes, length);
  // sortedIndexIterator will now give arrays of with the given length that
  // indicate what indexes into "elements" should be returned on each iteration.
  var sortedIndexIterator = goog.iter.filter(
      indexIterator, function(arr) { return goog.array.isSorted(arr); });

  var iter = new goog.iter.Iterator();

  function getIndexFromElements(index) { return elements[index]; }

  iter.next = function() {
    return goog.array.map(sortedIndexIterator.next(), getIndexFromElements);
  };

  return iter;
};

[MatrixFrog]

We're not really supporting ES6_TYPED nowadays except for parsing .d.ts files. I assume the error goes away if you go to ES6_STRICT mode instead?

[jart]

Yes I talked to the guy (forget his name) who was working on ES6_TYPED and he told me the same thing. I stopped documenting it in Closure Rules, but I still had some leftover typed unit tests (now deleted) which caused me to run into this bug. I wasn't sure if it was worth reporting this, since it makes no difference to me whether or not it's fixed. But I figured I'd do the right thing. Feel free to disregard and keep the issue for posterity. (Although I will say it's a shame that Google chose not to devote the resources to making Closure Compiler compete more directly with TypeScript. 😢)

[Dominator008]

@jart I doubt this is an ES6_TYPED specific issue since the example is not using any TypeScript syntax. Does the errors really go away with ES6_STRICT?

[MatrixFrog]

Closure Compiler is designed for people who are writing JavaScript, not for people writing something similar to JavaScript, such as Dart/CoffeScript/TypeScript/etc. There's a lot of discussion going on about the future of JS and TypeScript-style type annotations are of course part of that. But this is more a topic for the discussion list than for the issue tracker.

[Dominator008]

Reopening as this doesn't really use any TypeScript syntax. It's bad if people get wrong errors just by using a different language mode. Besides, since we don't have a separate language mode for externs, I can imagine a workflow that just passes in ES6_TYPED and I don't want to break that.

[jart]

Also @MatrixFrog I forgot to mention: Yes, I confirmed the error only happens when --language_in=ECMASCRIPT6_TYPED.

@Dominator008 Out of respect for @MatrixFrog, I'm going to re-close this issue and encourage you to start a thread on closure-compiler-discuss. If you start a thread there, I have a few things on my mind I'll happily contribute to the discussion.

[MatrixFrog]

I don't really care much if it's open or closed, as long as it's clear that we're unlikely to fix it in the forseeable future.

[ChadKillingsworth]

@jart Just an FYI - Dominator008 is a closure-compiler core contributor with commit access.

[jart]

Oh wow. I had no idea.

/me blushes and reopens issue.

[ChadKillingsworth]

Yeah - we no longer get badges on our comments. You just have to "know".