[cpp] Generate Sourcemap Style File #11590
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…elative cpp file paths
|
Do you think we could move these additions to another file? gencpp.ml is a bit of a monster, and while I don't plan to refactor anything there, it would at least be nice to not feed it more than necessary. |
|
Yes, I remember thinking it might make sense to move it into another file when I was originally working on it. Hopefully once I get around to replacing my custom format with one of the existing sourcemap generators the diff will come down a lot so I'll see what it looks like then. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Started this quite a while ago to try and improve the cpp target debugging experience by taking inspiration from the js world and have the compiler output a mapping file and then use DbgEng (underlying library of WinDbg and Visual Studio's debugger) to build a debugger which consumes that file. This worked pretty well and while I haven't worked on it much recently due to pulling out the libuv library from it to use as a base for asys, hxb among other things has had me thinking about it again recently.
So this PR is less about the changes as they are now and more about seeing what can be done to unify the various targets debug output and improve it further.
I originally didn't go with the js sourcemap format as its quite limited and at the time didn't know there was an extension mechanism in the standard to provide extra info, so my custom json could be binned. But there appear to be two source map generators in the compiler. One which is only used by the PHP generator and another which is used by js and lua. Which one should be used and is best open to extension to allow generators to provide extension data?
My format and js sourcemaps just contain a flat mapping between line and column positions, they don't store the original structure of the code. This can make implementing stuff like stepping a pain.
I was originally planning on dumping the entire ast in some sort of xml / heirarchy format to allow figuring out the best stepping behaviour for a given expression. I haven't look too deeply yet but it seems like hxb would be a good use for this.
Eventually I want to look at some of the stuff I mentioned in #10888 but thats a nice extra and I haven't figured out what and where the best way to store that info would be.