Remove source map 'names' field support #26149
Merged
+32
−22
Conversation
This file contains hidden or 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
We used 'names' field to encode the enclosing function name of a given offset, so that we can provide the correct source location + function info that can be used in displaying stack traces. I wasn't aware JS uses it for a very different purpose. JS uses it to display original variable/function names for minified names. In JS an 'offset' is a location in the minified JS code, and if that location happens to point to a minified variable name `a` whose original name was `apple`, its mapping contains `apple`. So while we can use this field to support emsymbolizer, the browser devtools is unlikely to ever implement the support for our 'names' field for stack traces, which is basically unrelated from what JS does. So this removes the support for the 'names' field. But it doesn't actually remove the implementation; it just puts it behind a fake flag that is set to `False` for now. The reason is, we want to provide this function info anyway for better stack traces support, and "Scopes" proposal for source maps, which was recently added, seems designed for this purpose. And I think we can reuse much of our current implementation (`extract_func_ranges`) to generate that format.
aheejin
commented
Jan 22, 2026
Comment on lines
-9675
to
-9677
| # The addresses, function names, and source locations are the same across | ||
| # the builds because they are relative offsets from the code section, so we | ||
| # don't need to recompute them |
Member
Author
There was a problem hiding this comment.
Unrelated, but this comment seems unnecessary anyway
sbc100
approved these changes
Jan 22, 2026
kripken
approved these changes
Jan 22, 2026
dschuff
approved these changes
Jan 22, 2026
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
We used 'names' field to encode the enclosing function name of a given offset, so that we can provide the correct source location + function info that can be used in displaying stack traces.
I wasn't aware JS uses it for a very different purpose. JS uses it to display original variable/function names for minified names. In JS an 'offset' is a location in the minified JS code, and if that location happens to point to a minified variable name
awhose original name wasapple, its mapping containsapple.So while we can use this field to support emsymbolizer, the browser devtools is unlikely to ever implement the support for our 'names' field for stack traces, which is basically unrelated from what JS does.
So this removes the support for the 'names' field. But it doesn't actually remove the implementation; it just puts it behind a fake flag that is set to
Falsefor now. The reason is, we want to provide this function info anyway for better stack traces support, and "Scopes" proposal for source maps, which was recently added, seems designed for this purpose. And I think we can reuse much of our current implementation (extract_func_ranges) to generate that format.Fixes #26100.