Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal for encoding source-level environment information #4

Open
wants to merge 1 commit into
base: master
from

Conversation

@fitzgen
Copy link
Member

fitzgen commented Jul 22, 2015

Proposal for #2.

Rendered Proposal

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.

@fitzgen
Copy link
Member Author

fitzgen commented Jul 22, 2015

@yurydelendik
Copy link

yurydelendik commented Aug 18, 2017

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++.

`"mappings"` property of the source map format, and has proved valuable in
reducing file size.

The `"env"` property can be parsed with the following BNF-like grammar, where

This comment has been minimized.

Copy link
@stefanpenner

stefanpenner Mar 28, 2018

Concatenation of source files, into final output files is extremely common.

One proposed aspect of sourceMap format are are sections. Although those haven't been commonly adopted, but if they were would both simplify the concatenation story and debuggers using sourceMaps story (complexity and performance) a.

Given that, I would like to recommend env also have envSections or something with a similar outcome?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants
You can’t perform that action at this time.