fix output of imported AST #2771
Conversation
|
(OT) Woah AppVeyor...:exclamation: |
|
... and this one is on GitHub: |
|
Meanwhile, Travis CI timed-out on Node.js 0.10 |
|
#2771 (comment) - related to removal of |
If that's the case I'd expect it to fail more regularly - full log for that job: |
|
But it appears to be backwards compatible and uglify handles the ESTree round trip... $ echo '"use strict"; function f(){ "use strict"; "use asm"; }' | bin/uglifyjs -p acorn -o spidermonkey | bin/uglifyjs -p spidermonkey -b
"use strict";
function f() {
"use strict";
"use asm";
}$ echo '"use strict"; function f(){ "use strict"; "use asm"; }' | node_modules/.bin/acorn | bin/uglifyjs -p spidermonkey -b
"use strict";
function f() {
"use strict";
"use asm";
} |
|
Just to confirm - it only presents an issue if somebody sends us an ESTree to parse that contains that new node type? |
The node stdout/stderr buffer bug is timing/load dependent. If downstream process can keep up with 64K buffering on Linux all appears well. |
Understood - I'm assuming there will be more instances of failure. So far I've only seen it once from AppVeyor (Windows) and none from Travis CI (Linux), but I shall keep an eye out. |
|
IIRC |
#2771 (comment) tested new ESTree input. I suppose uglify could emit the new ESTree |
I didn't realize the failure was only seen on Windows. That node subsystem is completely different than the UNIX implementation - and still is blocking as far as I know. |
|
Sorry for missing that second example which feeds directly from $ echo '"use strict"; function f(){ "use strict"; "use asm"; }' | acorn{
"type": "Program",
"start": 0,
"end": 57,
"body": [
{
"type": "ExpressionStatement",
"start": 0,
"end": 13,
"expression": {
"type": "Literal",
"start": 0,
"end": 12,
"value": "use strict",
"raw": "'use strict'"
},
"directive": "use strict"
},
{
"type": "FunctionDeclaration",
"start": 14,
"end": 54,
"id": {
"type": "Identifier",
"start": 23,
"end": 24,
"name": "f"
},
"generator": false,
"expression": false,
"params": [],
"body": {
"type": "BlockStatement",
"start": 26,
"end": 54,
"body": [
{
"type": "ExpressionStatement",
"start": 28,
"end": 41,
"expression": {
"type": "Literal",
"start": 28,
"end": 40,
"value": "use strict",
"raw": "'use strict'"
},
"directive": "use strict"
},
{
"type": "ExpressionStatement",
"start": 42,
"end": 52,
"expression": {
"type": "Literal",
"start": 42,
"end": 51,
"value": "use asm",
"raw": "'use asm'"
},
"directive": "use asm"
}
]
}
}
],
"sourceType": "script"
} |
|
It's there - see last line: {
"type": "ExpressionStatement",
"start": 28,
"end": 41,
"expression": {
"type": "Literal",
"start": 28,
"end": 40,
"value": "use strict",
"raw": "'use strict'"
},
"directive": "use strict"
},It's redundant as far as uglify parsing is concerned - it is handled via different means. |
|
Just to be clear, only this line was added for each of the "directive": "use strict" |
|
I see - thanks for the clarification 👍 |
|
Uglify would be more robust if it continued to ignore the new |
|
I'll leave that to whoever uses ESTree - there's also work to be done on |
Discovered by
test/mozilla-ast.jsFor ease of review: https://github.com/mishoo/UglifyJS2/pull/2771/files?w=1