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

merged 1 commit into from
Apr 12, 2023


Copy link

@fitzgen 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.

Copy link
Contributor Author

fitzgen commented Jul 22, 2015

Copy link

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
Copy link

@stefanpenner stefanpenner Mar 28, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link

Might as well land this; I'm looking forward to understanding how this relates to @hbenl's ideas. It'd be fine to have multiple competing proposals drafted here.

@littledan littledan merged commit 262e14b into tc39:master Apr 12, 2023
nicolo-ribaudo pushed a commit to nicolo-ribaudo/source-map that referenced this pull request Mar 13, 2024
Fix License, Status and added Introduction
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

Successfully merging this pull request may close these issues.

None yet

4 participants