feat: store local name in debug mode binary

[HerrCai0907]

The goal of PR is to output local variant name into wasm custom section and wat file for easier debug.

• I've read the contributing guidelines
• I've added my name and email to the NOTICE file

[dcodeIO]

One question that remains is whether local names should also be set when optimizing. From what I've seen, when optimizations are enabled and locals are merged or moved around, the names don't match anymore, which is not so much a problem in a binary, but is weird in optimized text format outputs which then don't make sense anymore. Could be prevented by only setting the names when !options.willOptimize or so.

[dcodeIO]

Or rather look for options.debug? Hmm. What do you folks think?

[MaxGraey]

Or rather look for options.debug? Hmm. What do you folks think?

I think it's better

[HerrCai0907]

Or rather look for options.debug? Hmm. What do you folks think?

I think it's better

I don't find options.debug.
Of course It's possible to add a new field to store this information, but I think the relationship between debug and willOptimize can be confusing and we need to add some warning for the usage like --debug -O2

[dcodeIO]

Ah, you are right, there is no parameter for debug info yet. I guess for now willOptimize is fine as it is only true if optimizeLevel = shrinkLevel = 0.

[dcodeIO]

What this doesn't solve, btw, just to note, is that scoped variables are shared. Say in

{
  let a = 1;
}
{
  let b = 2;
}

there is only one concrete local since a is freed and reused. Somewhat by design currently.

[HerrCai0907]

Is it possible to ignore free temp local in !options.willOptimize mode?

[dcodeIO]

Currently there is an unfortunate cross-dependency I believe that is introduced by a few places where code is re-compiled. What happens there is:

1. Compile the code the first time, sharing locals as needed
2. Free shared locals
3. Compile the code again, relying on shared locals obtaining the same indexes

Now, if locals weren't shared, re-compilation would produce garbage locals I think. I guess this would have to be tackled prior in order to guarantee proper names. Generally good to fix this eventually I think, and always use a dedicated local per name that isn't freed.

[MaxGraey]

Thanks!