-
Notifications
You must be signed in to change notification settings - Fork 857
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Resolve structural issue with exception handling in IRFactory #967
Comments
Rhino's (function() { /* comment */ if(1){}}).toString()
// output
function () {
if (1) {
}
} For example, this is what it looks like in SpiderMonkey now. (It used to be the same as Rhino) (function() { /* comment */ if(1){}}).toString()
// output
"function() { /* comment */ if(1){}}" Maybe the refactoring will eliminate the need for the |
Looks related: #406 |
@tuchida I see 3 things in this case:
With regards to 3: this should maybe be a separate issue? We also have #122, which is old but contains a lot of tests and changes to make those tests pass. Might be interesting to resurrect that PR Couldn't 2 be fixed, without a complete overhaul of the IRFactory? And are you going to work on 1? If so, shall I assign the issue to you? |
I can't promise that I'll fix it. I'm sorry.
|
no worries, gonna update the description a bit to better represent what this issue is about then |
It's a small detail, but it seems that |
I am not sure, but perhaps this is not right. First, I want to change this to delegation. |
IDK, not very (or basically not) familiar with this part of Rhino, maybe others have some insight on this, sry |
I am in the process of fixing it, but I would like to modify it in this way.
I believe that this fix is necessary if we are going to add the latest ECMA262 features to Rhino in the future. When I actually tried to add Computed Property Names and default parameters, I had trouble with the I would like to discuss with you what kind of pull requests you can accept. |
Hi @tuchida, great to hear you're working on this! As I mentioned before, I don't have much insight into this area of Rhino, but in general any change that fixes problems and gets us closer to EcmaScript compatibility is a good thing imho. Whether such a (big) change can be accepted depends (again imho) on the potential impact, in area's of performance and backwards compatibility. I tried to look through the changes, but the first thing I noticed was that interspersed with the actual changes were a lot of formatting changes. I think it would make sense to split out the formatting changes from the other changes and create a separate PR for those, so the actual changes become easier to review. And if you're up for it: why not add all the remaining formatting of src files while at it, as per #1024 |
And oh: if this helps/is required for the implementation of Computed Property Names and default parameters I'm all for it 👍 |
ref. master...tuchida:refactor-IRFactory
Presumably this can be enabled test262 by corresponding to #958. |
Can you make a (draft) PR of your branch and maybe a comment on that PR what state is in (wip/prototype/ready for merge/...)? |
@tuchida you wrote earlier that this issue was hampering you when trying to implement Computed Property Names. Now that the IRFactory part is merged, any change that your Computed Properties work is any closer to finishing maybe? |
@tuchida other questions for you: as the 'IRFactory inherit from Parser' part of this case is now done:
|
I just tried $ java -jar rhino-1.7.15-SNAPSHOT.jar -version 200
Rhino 1.7.15-SNAPSHOT
js> 1 = 1
js: line 1: Invalid assignment left-hand side.
js:
js: ^
Exception in thread "main" org.mozilla.javascript.Parser$ParserException
at org.mozilla.javascript.Parser.reportError(Parser.java:339)
at org.mozilla.javascript.Parser.reportError(Parser.java:325)
at org.mozilla.javascript.Parser.reportError(Parser.java:320)
at org.mozilla.javascript.IRFactory.createAssignment(IRFactory.java:2304)
at org.mozilla.javascript.IRFactory.transformAssignment(IRFactory.java:446)
at org.mozilla.javascript.IRFactory.transform(IRFactory.java:219)
at org.mozilla.javascript.IRFactory.transformExprStmt(IRFactory.java:557)
at org.mozilla.javascript.IRFactory.transform(IRFactory.java:216)
at org.mozilla.javascript.IRFactory.transformScript(IRFactory.java:1129)
at org.mozilla.javascript.IRFactory.transform(IRFactory.java:198)
at org.mozilla.javascript.IRFactory.transformTree(IRFactory.java:118)
at org.mozilla.javascript.Context.parse(Context.java:2517)
at org.mozilla.javascript.Context.compileImpl(Context.java:2434)
at org.mozilla.javascript.Context.compileString(Context.java:1402)
at org.mozilla.javascript.Context.compileString(Context.java:1390)
at org.mozilla.javascript.tools.shell.Main.processSource(Main.java:480)
at org.mozilla.javascript.tools.shell.Main.processFiles(Main.java:180)
at org.mozilla.javascript.tools.shell.Main$IProxy.run(Main.java:98)
at org.mozilla.javascript.Context.call(Context.java:544)
at org.mozilla.javascript.ContextFactory.call(ContextFactory.java:475)
at org.mozilla.javascript.tools.shell.Main.exec(Main.java:164)
at org.mozilla.javascript.tools.shell.Main.main(Main.java:142) Is that the correct exception to be thrown? |
If #1188 is merged, it will look like this
|
Right, I see now... |
Glad to see there is already progress on this. I just rediscovered the same bug. First I accidentally tried |
In the example below, one can see that the
IRFactory
throws aParserException
when in this case aSyntaxException
ought to be thrown.Further down comment #967 (comment) points to a fix that results in the proper Error being thrown, but proper location info is missing.
These issues ought to be fixed, possibly requiring the refactoring of the
IRFactory
as suggested below#853 (comment)
If I evaluate
1=1
, I will expect only JavaScript error, but Java exception will be thrown.Parser$ParserException
is private class. There is something strange about this being thrown out ofParser
.There are probably two problems with this. (I'm sorry if I'm wrong.)
1.
IRFactory
inheritance ofParser
This makes it difficult to know where to catch the
Parser$ParserException
.I felt that
IRFactory
inheritance ofParser
was an anti-pattern of Code reuse via inheritance.2. Reanalyzing the entire AST.
Rhino parser seems to work as follows.
Parser
make AST from source code.IRFactory
,Decompiler
reverts the all AST to source code.IRFactory
andParser
will reanalyze the source code.The syntax of ECMAScript is ambiguous and some things need to be reanalyzed.
https://262.ecma-international.org/12.0/#sec-syntactic-grammar
However, it should only be necessary to reanalyze the grammar that write "cover".
The text was updated successfully, but these errors were encountered: