Improved variable names in generated JS

[RunDevelopment]

This PR implements a change I wanted to do for a while. The bindings defined JS variables inconsistently, using const, let, and var all over the place. As it turns out, most variables can be declared as const and everything else can be var. So I create a simple API for creating variables. This API also takes care of resolving naming conflicts, so we'll never have to worry about temporary variables conflicting with argument names ever again. In the future, this system may also be used to resolve other naming conflicts, but I kept it simple for now.

For those needing a refresher on var, let, and const in JS:

• const name = value: A block-scoped variable that cannot be reassigned.
• let name = value: A block-scoped variable that can be reassigned.
• var name = value: A function-scoped variable that can be reassigned.

Changes:

• New API for JsBinding that handles the creating of variables. The new function automatically resolves name conflicts and ensure that temporary variable names never conflict with parameter names. The main functions of the new API are:
  • alias(name, expr): This creates a JS const variable. The variable is immutable.
  • var(name, initial): This creates a JS var variable. The variable is mutable AND visible in the finally block.
  • guarnatee_alias: Same as alias, but panics if the name is taken. This is necessary, because one instruction assumes that a variable called retptr has been created, so we can't rename that variable.
• Use the new API everywhere. All variables are now created with the new API.

[RunDevelopment]

Please merge #4281 before this PR, because it includes code gen for most of the binding instructions this PR changes.

[daxpedda]

I don't know what to think of the change from let to var. I always read to not use var. After some research, it also seems to be the recommendation I find most. Personally, var make it just harder to read code compared to let. Is there some guidance somewhere we could follow?

The deferred stuff makes sense to me to use var on, but on anything else I would prefer to stick with let, const taking precedence over both ofc.

[RunDevelopment]

The reason I didn't use let is to minimize the API of JsBuilder.

The only difference between var and let inside function bodies is that var is function-scoped while let is block-scoped. Both can be re-assigned, but only var can be accessed from anywhere within the function. So let is strictly less powerful than var. That power is also the reason let was added to JS. Turns out, people make coding mistakes and var makes it easy to use a variable before it is defined. Example:

try {
  throw new Error();
  var foo = 42;
} catch {
  console.log(foo);
}

Accessing foo inside the catch block before it has been assigned a value is valid and will log undefined. Did you expect this? If no, then you now know the reason people say you shouldn't use var. People are very used to block-scoped variables from other programming languages, and so var goes against their intuition.

Btw the reason the above logs undefined is that var foo is not block-scoped. So the above is executed by JS like this:

let foo = undefined;
try {
  throw new Error();
  foo = 42;
} catch {
  console.log(foo);
}

Now the behavior is a bit more clear, right?

Why did I use var everywhere, then? Again, to minimize the API, and because most of the reasons people recommend let over var don't apply to us. The code is generated, so human error in writing code doesn't really apply, and scoping rules of var are actually useful to us because they make code gen a bit easier.

I just don't see the point in adding support for let when var already does everything let can do and more.

[daxpedda]

Now the behavior is a bit more clear, right?

I was already aware of all that. AFAIU to me it all boils down to scoping and hoisting vs TDZ. My personal preference is let because I find function level scoping horrible to read and if I've had to choose between temporal dead zoning and hoisting I would pick TDZ.

Why did I use var everywhere, then? Again, to minimize the API, and because most of the reasons people recommend let over var don't apply to us. The code is generated, so human error in writing code doesn't really apply, and scoping rules of var are actually useful to us because they make code gen a bit easier.

I agree that we should prioritize WBG over the output. But the readability of the generated output is not worth nothing. E.g. removing the complexity around deferred in the implementation is a plus in my book. But the cost of using let in all the other cases seems incredibly small to me especially because it is very self-contained with the new changes you made. I would definitely not like to decrease the readability of the code unless the tradeoff makes sense, even if its not a priority.

So unless there are other reasons to use var, lets stick with let apart from the deferred stuff.

[RunDevelopment]

Done. I used let wherever possible.

I also added reference tests for closures, because they had some code gen unique to them.

[RunDevelopment]

I'm going insane. Code gen for closures isn't consistent between compilers. I'm not having another raw.js. Bye bye closure reference tests.

[daxpedda]

Shouldn't we just be able to use var here and skip a line, like in deferred?

[RunDevelopment]

With the introduction of let, the purpose of var has now become to declare variables as accessible from within the finally block.

The goal is to generate correct JS code, not code golfing.

[daxpedda]

In lack of a proper response: please use var here.