When using the "//@sourceURL=" annotation in an eval()'d string, the source location will show up in the debugger, including using the specified sourceURL. However, no source location information is available for such "scripts" in the profiler.
Created attachment 55261 [details] test case showing problem
Created attachment 55264 [details] screenshot showing problem The orange round-rectangles, pointed to by the red arrows, show where the source location should be displayed, but isn't.
Looks to me, like the best approach here is to arrange for the sourceID to come in from the profiling data (it currently is NOT), and then do the sourceID lookup against the _sourceIDMap in ScriptPanel back in JavaScript. The ScriptsPanel should have access to the sourceURL, which is parsed in the Script class. ScriptPanel would need to be extended to provide an sourceID->Script lookup function. One place to start looking where to get the sourceID sent back from the profiler is in CallIdentifier (JSC/profiler/CallIdentifier.h). Various places in JSC/profiler/ProfileGenerator.cpp, for instance, create CallIdentifer AND have access to the sourceID. I'm not entirely certain whether the sourceID in the profiler is the same as the one that comes into the ScriptPanel, but initial checks seem to indicate that they are. All this is just for JSC; V8 would need a different but similar set of changes, presumably. Seems kind of expensive, in terms of code hits, for a missing feature not many people have missed. One note though - message sends from the profiler into WI, seem to be sending the sourceURL all the time. If we sent the sourceID instead, we could look up the sourceURL in WI JavaScript code (as suggested above). Could be a savings there. That may even flow back farther in the Profiling code - perhaps we don't really need to ever have the sourceURL available to the profiler if the sourceID is available instead.
<rdar://problem/16615742>
Is this an issue with the new sampling profiler?
The bug title specifically mentions `eval()`, which was one weird trick to do sourcemap-py stuff 6 years ago. If the bug only impacts `eval()` usage of sourcemaps, I doubt this is going to affect anyone.
Attached test case works as expected in the new profiler.