1499066 - Consider adding best-effort location information to JS symbols

Status: NEW

(Webtools :: Searchfox, enhancement)

Description

[Andrew Sutherland [:asuth] (he/him)]

non-local JS symbols are given global searchfox symbol names due to current limitations on analysis.  See a longer discussion at https://bugzilla.mozilla.org/show_bug.cgi?id=1497914#c10 but, in short, searchfox has two layers of information for search results: identifiers, and symbols.  When a search is done, we check the identifier list.  For each matching identifier, there are one or more result symbols.  This allows us to have completely arbitrary synthetic symbols such as those used for defined C pre-processor symbols which take the form of `M_${hashcode(location_info)}` (see bug 1497914 for more).

This means that we are able to partition existing searchfox symbols further without loss of generality as long as they are still linked to the same identifier.  The main caveat is that the context menu jumps/searches list currently operates on lists of symbols.  The plan there is that a context menu row would exist for the locally defined/inferred symbol as well as a row for the catch-all identifier.

So the rough proposal is:
- For the default case, embed the rough module/sub-module path of where the JS code lives to provide likely locality.  For example, the sub-directories of dom/ and testing/web-platform/tests/ each form islands of JS test logic.
- For cases where we can do better due to explicit semantics, like when .jsm files are involved or ES modules, use the actual JSM/module name.