Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Proposal for encoding source-level environment information #4
Proposal for #2.
I've tried to make this precise and detailed, perhaps at the cost of some brevity, but I was also not 100% sure how detailed and specific to be at times. I am very open to suggested changes, particularly anything that is not clear to potential implementers.
Looking forward to feedback.
Here is a couple of thoughts related to the information expressed in encoded scopes. The first one is that scopes will be better expressed in "source location" locations. The good example of the transform, where it will be useful, is a function inlining -- the function scope is not really belong to the chain in the generated scopes where the body is inlined. (Bound locals/params need to rely on generated locations, see the thought below) It might be useful to have mapping of the generated scopes mapped to original locations to avoid guessing, when debugger is trying to resolve binding values.
The second thought is to replace BindingValue to something more like an expression, e.g. encoding folded constant, locals in an unrolled loop, or an eliminated induction variable. Notice that a binding may change its value in the same scope within generated source -- it can complicate value resolution though. Expression-like values is useful to build more "structural" value e.g. for asm.js/wasm generated from C/C++.