"already defined in this object literal" parse error when using ES5 getter & setter with same prop name (in strict mode only?)

[GoogleCodeExporter]

What steps will reproduce the problem?

closurecompiler --language_in ECMASCRIPT5_STRICT --compilation_level 
ADVANCED_OPTIMIZATIONS <<EOT
'use strict';
function App() {}
App.prototype = {
  get appData() { return this.appData_; },
  set appData(data) { this.appData_ = data; }
};
EOT

What is the expected output? What do you see instead?
I expect no errors.  Instead I see:

stdin:5: ERROR - Parse error. Property "appData" already defined in this object 
literal.
  set appData(data) { this.appData_ = data; }
                                             ^

1 error(s), 0 warning(s)

What version of the product are you using? On what operating system?

Version: 1346
Built on: 2011/08/11 15:02,

[G]Ubuntu 10.04.2 LTS

Please provide any additional information below.
Happens only when using string literal 'use strict'; to trigger strict mode.

NOTE: I think there's a second bug here, as when you run `closurecompiler 
--version` I expect it to spit out a version and not go into stdin compilation 
mode, but it continues to wait for stdin.  Perhaps this is a feature, though?

Original issue reported on code.google.com by db...@google.com on 16 Nov 2011 at 7:31

[GoogleCodeExporter]

Thanks for the report.

Original comment by concavel...@gmail.com on 16 Nov 2011 at 11:53

• Changed state: Accepted

[GoogleCodeExporter]

I can't reproduce this with the latest build.

Original comment by concavel...@gmail.com on 17 Nov 2011 at 1:11

[GoogleCodeExporter]

still happening for me on r1459:

$ ./compiler.jar --language_in ECMASCRIPT5_STRICT --compilation_level 
ADVANCED_OPTIMIZATIONS <<EOT
'use strict';
function App() {}
App.prototype = {
  get appData() { return this.appData_; },
  set appData(data) { this.appData_ = data; }
};
EOT

stdin:5: ERROR - Parse error. Property "appData" already defined in this object 
literal.
  set appData(data) { this.appData_ = data; }
                                             ^

1 error(s), 0 warning(s)

$ ./compiler.jar --version
Closure Compiler (http://code.google.com/closure/compiler)
Version: 20111003 (revision 1459)
Built on: 2011/10/03 11:29

Original comment by dbeam@chromium.org on 17 Nov 2011 at 1:59

[GoogleCodeExporter]

I reproduced this. It appears to be a rhino parser bug.  You can work around 
the problem by removing the "use strict" from the input source.  The source 
will still be checked by the compiler but no by rhino.

Original comment by concavel...@gmail.com on 21 Nov 2011 at 5:44

[GoogleCodeExporter]

> You can work around the problem by removing the "use strict" from the input 
source.

Yup, I put that in the additional information.

<rant>
I thought the point of 'use strict'; as a string literal is that it's just a 
no-op statement that works backward compatibly, lol, but I guess not *all* the 
time.
</rant>

I just imagine putting 'use strict'; at the top of a file or inside a function 
is a relatively common use case for those wanting to use ES5 strict mode, no?  
For instance, we do something like this:

  cr.define('ntp4', function() {
    'use strict';
    // strict mode scoped per module
  });

all over the New Tab page in Chrom{e,ium}.  This bug was derived by trying to 
run the compiler on our code (http://goo.gl/zDQyw) as a @return type enforcer 
to prevent bugs.  I imagine we'd like to continue using strict mode.  Your 
workaround is great for reading via closure compiler, but we'd have to find 
some other way of signalling to Chrom{e,ium} to use ES5 strict mode, which is 
kinda lame or do some egrep -v [\'\"]use\ strict[\'\"] hack before we run the 
closure compiler.

Original comment by db...@google.com on 21 Nov 2011 at 7:50

[GoogleCodeExporter]

To be clear, this will get fixed soon. John was just suggesting an immediate 
solution if you needed it.

Original comment by Nicholas.J.Santos on 21 Nov 2011 at 8:29

[GoogleCodeExporter]

This issue was closed by revision r1628.

Original comment by `` on 22 Nov 2011 at 1:00

• Changed state: Fixed

[GoogleCodeExporter]

Awesome!  Thanks for the quick turn around!

Original comment by db...@google.com on 22 Nov 2011 at 1:05