Re: Review request for JDK-8133300: Ensure symbol table immutability in Nashorn AST

Reviewed new webrev. Happy +1 /M > On 31 Aug 2015, at 12:09, Attila Szegedi wrote: > > I posted another webrev, can you please review: > http://cr.openjdk.java.net/~attila/8133300/webrev.01.jdk9 > > The only changes are: > - added Ja

Re: RFR 8134731: `Function.prototype.apply` interacts incorrectly with `arguments`

+1. Any regression on raytrace, though? /M > On 31 Aug 2015, at 13:35, Sundararajan Athijegannathan > wrote: > > Please review http://cr.openjdk.java.net/~sundar/8134731/ for > https://bugs.openjdk.java.net/browse/JDK-8134731 > > Thanks > -Sundar

Re: RFR 8134731: `Function.prototype.apply` interacts incorrectly with `arguments`

It can’t regress on raytrace, since raytrace uses: return function() { this.initialize.apply(this, arguments); } that is, the function containing the transform declares no arguments. Attila. > On Sep 1, 2015, at 9:15 AM, Marcus Lagergren wrote: > > +1. Any regression on raytrace

Re: RFR 8134731: `Function.prototype.apply` interacts incorrectly with `arguments`

Yes. And I manually inspected generated bytecode to make sure no-declared-param function case is handled by apply2call opt. -Sundar On 9/1/2015 1:51 PM, Attila Szegedi wrote: It can’t regress on raytrace, since raytrace uses: return function() { this.initialize.apply(this, argumen

Re: RFR 8134731: `Function.prototype.apply` interacts incorrectly with `arguments`

Awesome. Good diagnosis, Sundar! +1 /M > On 01 Sep 2015, at 10:57, Sundararajan Athijegannathan > wrote: > > Yes. And I manually inspected generated bytecode to make sure > no-declared-param function case is handled by apply2call opt. > > -Sundar > > On 9/1/2015 1:51 PM, Attila Szegedi wrot

RFR 8068901: Surprising behavior with more than one functional interface on a class , 8068903: Can't invoke vararg @FunctionalInterface methods

Please review http://cr.openjdk.java.net/~sundar/8068901_8068903/ for https://bugs.openjdk.java.net/browse/JDK-8068901 and https://bugs.openjdk.java.net/browse/JDK-8068903 Thanks, -Sundar

Re: RFR 8068901: Surprising behavior with more than one functional interface on a class , 8068903: Can't invoke vararg @FunctionalInterface methods

Elegant small solution with use of dyn:callMethod. One small thing: ClassValue FUNCTIONAL_IFACE_METHOD could now be ClassValue FUNCTIONAL_IFACE_METHOD_NAME instead. > On Sep 1, 2015, at 1:00 PM, Sundararajan Athijegannathan > wrote: > > Please review http://cr.openjdk.java.net/~sundar/8068

Re: RFR 8068901: Surprising behavior with more than one functional interface on a class , 8068903: Can't invoke vararg @FunctionalInterface methods

Thanks for the review. Updated: http://cr.openjdk.java.net/~sundar/8068901_8068903/webrev.01/ Thanks, -Sundar On 9/1/2015 4:55 PM, Attila Szegedi wrote: Elegant small solution with use of dyn:callMethod. One small thing: ClassValue FUNCTIONAL_IFACE_METHOD could now be ClassValue FUNCTIO

Re: RFR 8068901: Surprising behavior with more than one functional interface on a class , 8068903: Can't invoke vararg @FunctionalInterface methods

Updated further: (method names changed to state "MethodName") http://cr.openjdk.java.net/~sundar/8068901_8068903/webrev.02/ Thanks, -Sundar On 9/1/2015 5:20 PM, Sundararajan Athijegannathan wrote: Thanks for the review. Updated: http://cr.openjdk.java.net/~sundar/8068901_8068903/webrev.01/ T

RFR 8134865: Need to restore for container block from lexical context in finally

Please review http://cr.openjdk.java.net/~aw/8134865/ for https://bugs.openjdk.java.net/browse/JDK-8134865 In forStatement(), restoreBlock() was not called on exception in ES6 language mode, which lead to an AssertionError. I've added some minor cleanups on top. Thanks, Andreas

Re: RFR 8068901: Surprising behavior with more than one functional interface on a class , 8068903: Can't invoke vararg @FunctionalInterface methods

+1 > On Sep 1, 2015, at 2:06 PM, Sundararajan Athijegannathan > wrote: > > Updated further: (method names changed to state "MethodName") > http://cr.openjdk.java.net/~sundar/8068901_8068903/webrev.02/ > > Thanks, > -Sundar > > On 9/1/2015 5:20 PM, Sundararajan Athijegannathan wrote: >> Thank

Re: RFR 8068901: Surprising behavior with more than one functional interface on a class , 8068903: Can't invoke vararg @FunctionalInterface methods

+1 Am 2015-09-01 um 14:06 schrieb Sundararajan Athijegannathan: Updated further: (method names changed to state "MethodName") http://cr.openjdk.java.net/~sundar/8068901_8068903/webrev.02/ Thanks, -Sundar On 9/1/2015 5:20 PM, Sundararajan Athijegannathan wrote: Thanks for the review. Updated:

Re: RFR 8134865: Need to restore for container block from lexical context in finally

Looks good; +1 > On Sep 1, 2015, at 2:31 PM, Andreas Woess wrote: > > Please review http://cr.openjdk.java.net/~aw/8134865/ for > https://bugs.openjdk.java.net/browse/JDK-8134865 > > In forStatement(), restoreBlock() was not called on exception in ES6 language > mode, which lead to an Asserti

Re: RFR 8134865: Need to restore for container block from lexical context in finally

Hi, lower-case thumbs up from me. I'll sponsor this. Thanks, Michael > Am 01.09.2015 um 15:08 schrieb Attila Szegedi : > > Looks good; +1 > >> On Sep 1, 2015, at 2:31 PM, Andreas Woess wrote: >> >> Please review http://cr.openjdk.java.net/~aw/8134865/ for >> https://bugs.openjdk.java.net/b

RFR 8134873: Implement support for ES6 numeric literals

Please reviewhttp://cr.openjdk.java.net/~aw/8134873/ forhttps://bugs.openjdk.java.net/browse/JDK-8134873 Implements Lexer/Parser support for ECMAScript 6 binary (0b) and octal (0o) literals. I've renamed OCTAL (legacy octal literal, e.g. 0777) to OCTAL_LEGACY and added OCTAL and BINARY_LITERA

Re: RFR 8134873: Implement support for ES6 numeric literals

Do you want to pass a flag to Lexer for ES6 and control these ES6 specific stuff only under that flag? Much like -scripting is handled? -Sundar On 9/1/2015 8:00 PM, Andreas Woess wrote: Please reviewhttp://cr.openjdk.java.net/~aw/8134873/ forhttps://bugs.openjdk.java.net/browse/JDK-8134873 I

Re: RFR 8134873: Implement support for ES6 numeric literals

- How about we use BINARY_NUMBER instead of BINARY_LITERAL? I know this is bikeshedding… It’s still more consisent with other literal token types (e.g. NULL and STRING) that don’t have the _LITERAL suffix. If we made it consistent the other way round, we’d have to have NULL_LITERAL, STRING_LITER

Re: RFR 8134873: Implement support for ES6 numeric literals

Bikeshedding is welcomed :) I've uploaded a new webrev[1] with s/BINARY_LITERAL/BINARY_NUMBER/ and an es6 flag in Lexer as suggested by Sundar. [1] http://cr.openjdk.java.net/~aw/8134873/webrev.01/ Thanks, Andreas On 01/09/15 16:42, Attila Szegedi wrote: - How about we use BINARY_NUMBER inst

RFR 8134887: nashorn ant test configuration should disable assertion for LamdaFormEditor class

Please review http://cr.openjdk.java.net/~sundar/8134887/ for https://bugs.openjdk.java.net/browse/JDK-8134887 Thanks, -Sundar

Re: RFR 8134887: nashorn ant test configuration should disable assertion for LamdaFormEditor class

+1 > On Sep 1, 2015, at 2:13 PM, Sundararajan Athijegannathan > wrote: > > Please review http://cr.openjdk.java.net/~sundar/8134887/ for > https://bugs.openjdk.java.net/browse/JDK-8134887 > > Thanks, > -Sundar

Re: RFR 8134873: Implement support for ES6 numeric literals

+1 PS. After few more changesets are done, perhaps we should perhaps have "negative es6" tests. i.e., attempt es6 constructs in default es5 mode and expect syntax errors. -Sundar On 9/1/2015 8:35 PM, Andreas Woess wrote: Bikeshedding is welcomed :) I've uploaded a new webrev[1] with s/BINAR