closure-compiler icon indicating copy to clipboard operation
closure-compiler copied to clipboard

@override no longer copies typing information

Open vapier opened this issue 3 months ago • 3 comments

this seems to be a regression between v20201102 & v20201207. here's an example:

class foo {
  /**
   * Delete everything in this storage.
   *
   * @return {!Promise<void>} When clearing has completely.
   */
  async clear() {}
}

class fooBar extends foo {
  /** @override */
  async clear() {
    return new Promise((resolve) => {
      resolve();
    });
  }
}

in version v20201102 and older, we see no errors:

$ closure-compiler --version
Closure Compiler (http://github.com/google/closure-compiler)
Version: v20201102
$ closure-compiler --jscomp_error='*' --checks-only test.js 

but after upgrading to v20201207 (v20250820 behaves the same), we see:

$ closure-compiler --version
Closure Compiler (http://github.com/google/closure-compiler)
Version: v20201207
$ closure-compiler --jscomp_error='*' --checks-only test.js 
test.js:12:8: ERROR - [JSC_MISSING_RETURN_JSDOC] Function with non-trivial return must have JSDoc indicating the return type. Please see go/tsjs-problematic-patterns for why @overrides require explicit @return types..
  12|   async clear() {
              ^^^^^^^^^
  13|     return new Promise((resolve) => {
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
  15|     });
      ^^^^^^^
  16|   }
      ^^^

1 error(s), 0 warning(s), 94.8% typed

copying the typing info by hand makes it go away, but the documentation says this isn't necessary:

https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler#override If no other annotations are included, the method or property automatically inherits annotations from its superclass.

i'm guessing this is commit 777ab366ab0deaf4bbfc56523cbe3afe0aae63aa by @rishipal. the associated internal bug suggests this change was made because of a bug in Clutz -- it didn't actually implement the @override semantics. i grok that maybe for internal Google code, since JS->TS was a temporary migration, forcing people to duplicate typing was reasonable, but i don't know why that policy decision was made in the external closure-compiler version.

vapier avatar Dec 02 '25 02:12 vapier

Your repro specifically uses async functions. Was that necessary, or do you have the same problem with normal functions?

We suspect that we intentionally changed the behavior to always require explicit type information on overriden functions. We'll need to see if we can find that information and update the documentation appropriately.

brad4d avatar Dec 03 '25 17:12 brad4d

@blickly has agreed to look into this. Thanks, Ben.

brad4d avatar Dec 03 '25 17:12 brad4d

It happens on non-async too. I just grabbed the first set of failures and reduced it down.

vapier avatar Dec 03 '25 17:12 vapier