[Flight] Parse Stack Trace from Structured CallSite if available #33135
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
github-actions
bot
added
the
React Core Team
sebmarkbage
force-pushed
the
structuredparse
branch
from
0c177dc to
72bc9a6
Compare
sebmarkbage
force-pushed
the
structuredparse
branch
from
78d60d9 to
f862175
Compare
Since we can only trigger prepareStackFrame once, it's important to cache this since the second time it gets accessed we won't be able to get to it.
sebmarkbage
force-pushed
the
structuredparse
branch
from
f862175 to
dd0eaba
Compare
eps1lon
approved these changes
May 7, 2025
| } | ||
| // At the same time we generate a string stack trace just in case someone | ||
| // else reads it. Ideally, we'd call the previous prepareStackTrace to |
There was a problem hiding this comment.
We might have to call the previous one regardless in case the previous one is a custom one that also contains side-effects. Or do that in Next.js depending on the timing. The tricky bit is figuring how if that's the native one we want to avoid because it would be wasteful to call that.
| return String(error.stack); | ||
| } finally { | ||
| Error.prepareStackTrace = previousPrepare; | ||
| const identifierRegExp = /^[a-zA-Z_$][0-9a-zA-Z_$]*$/; |
There was a problem hiding this comment.
Why do we need to test that? Asking because people already complain that our lint rules don't allow unicode characters in Component names so this may come up again here.
There was a problem hiding this comment.
I'm trying to mirror what V8 does as much as possible so we get the same from parsing and not.
https://github.com/v8/v8/blob/main/src/objects/call-site-info.cc#L767
However, I didn't dig into what isIdentifier does since you get lost in codegen. I just saw others do this. Usually what I do is this:
github-actions bot
pushed a commit
that referenced
this pull request
May 7, 2025
) This is first step to include more enclosing line/column in the parsed data. We install our own `prepareStackTrace` to collect structured callsite data and only fall back to parsing the string if it was already evaluated or if `prepareStackTrace` doesn't work in this environment. We still mirror the default V8 format for encoding the function name part. A lot of this is covered by tests already. DiffTrain build for [0ff1d13](0ff1d13)
sebmarkbage
added a commit
that referenced
this pull request
May 7, 2025
… fake function (#33136) Stacked on #33135. This encodes the line/column of the enclosing function as part of the stack traces. When that information is available. I adjusted the fake function code generation so that the beginning of the arrow function aligns with these as much as possible. This ensures that when the browser tries to look up the line/column of the enclosing function, such as for getting the function name, it gets the right one. If we can't get the enclosing line/column, then we encode it at the beginning of the file. This is likely to get a miss in the source map identifiers, which means that the function name gets extracted from the runtime name instead which is better. Another thing where this is used is the in the Performance Track. Ideally that would be fixed by https://issues.chromium.org/u/1/issues/415968771 but the enclosing information is useful for other things like the function name resolution anyway. We can also use this for the "View source for this element" in React DevTools.
github-actions bot
pushed a commit
that referenced
this pull request
May 7, 2025
… fake function (#33136) Stacked on #33135. This encodes the line/column of the enclosing function as part of the stack traces. When that information is available. I adjusted the fake function code generation so that the beginning of the arrow function aligns with these as much as possible. This ensures that when the browser tries to look up the line/column of the enclosing function, such as for getting the function name, it gets the right one. If we can't get the enclosing line/column, then we encode it at the beginning of the file. This is likely to get a miss in the source map identifiers, which means that the function name gets extracted from the runtime name instead which is better. Another thing where this is used is the in the Performance Track. Ideally that would be fixed by https://issues.chromium.org/u/1/issues/415968771 but the enclosing information is useful for other things like the function name resolution anyway. We can also use this for the "View source for this element" in React DevTools. DiffTrain build for [4a70286](4a70286)
This was referenced May 8, 2025
This was referenced May 15, 2025
This was referenced May 21, 2025
17 tasks
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.
This is first step to include more enclosing line/column in the parsed data.
We install our own
prepareStackTraceto collect structured callsite data and only fall back to parsing the string if it was already evaluated or ifprepareStackTracedoesn't work in this environment.We still mirror the default V8 format for encoding the function name part. A lot of this is covered by tests already.