Javascript interpreter should not remove extra code blocks

RESOLVED INVALID

Status

()

--
major
RESOLVED INVALID
7 years ago
6 years ago

People

(Reporter: ajuhos, Unassigned)

Tracking

({js1.5, js1.6, js1.7})

14 Branch
x86_64
Windows 7
js1.5, js1.6, js1.7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [js:p3]DUPEME)

(Reporter)

Description

7 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.52 Safari/536.5

Steps to reproduce:

I created a code block inside a code block, eg:
function test() {
  var a = 4;
  {
    var b = 5;
  }
  return a + b;
}
console.log(test);


Actual results:

The interpreter removes the extra code block, so the logged message will be:
function test() {
  var a = 4;
  var b = 5;
  return a + b;
}


Expected results:

The block should be preserved, because I may had a reason to write it, so the output should be exactly the same as my script:
function test() {
  var a = 4;
  {
    var b = 5;
  }
  return a + b;
}

In the specific case where the error happend I defined a custom keyword which should be followed by a block and my library would parse the method and compile into another before executing it, but it won't work, because Firefox removes the block.

My library works in every browser except Firefox, including old versions of Internet Explorer too. So I think this kind of code optimalization is a bug and should not be done.
(Reporter)

Updated

7 years ago
Severity: normal → major
Keywords: js1.5, js1.6, js1.7
The behavior is perfectly fine per spec.  In particular, all it's doing is serializing the parsed representation of the function, which does certain semantics-preserving transformations (whitespace normalization, ASI, and so forth).

Other browsers just save the original function text instead of serializing the parsed representation, but that uses more memory, obviously.

Your real problem is that you're imposing additional semantics that the interpreter has no way to know about and then relying on them being preserved.  There's no such guarantee in the ECMAScript specification.  If that's what you need, you should be using strings, not JS source.
Whiteboard: DUPEME

Comment 2

7 years ago
Incidentally, we may move to "saving the source" with bug 678037.
Depends on: 761723
Whiteboard: DUPEME → [js:p3]DUPEME
This bug is INVALID as bz said. Saving source may fix it but that wouldn't be the point of saving source (as Luke wrote, "Incidentally").

/be
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.