Issue link in LLVM tree goes to BMO
Categories
(Webtools :: Searchfox, defect)
Tracking
(Not tracked)
People
(Reporter: botond, Unassigned)
References
Details
Steps to reproduce
- Go to https://searchfox.org/llvm/rev/4ed696c34869233362395b78a52191e5c39f8a18/clang-tools-extra/clangd/SystemIncludeExtractor.cpp
- Hover over the vertical ruler next to line 91. A tooltip appears with the commit message "[clangd] Support
-stdlibflags in SystemIncludeExtractor. (#69283) ". - Click on the "#69283" (which is linkified).
Actual results
I'm taken to https://bugzilla.mozilla.org/show_bug.cgi?id=69283
Expected results
I'm taken to https://github.com/llvm/llvm-project/pull/69283
(Though sometimes commit messages reference issue numbers which go to https://github.com/llvm/llvm-project/issue/XXXXX; not sure if there's a way to do an either/or.)
|
||
Comment 1•2 years ago
|
||
Linkification is currently fairly stateless so this would at least a tiny overhaul to allow for configuration. This could also pair well with bug 1847297 in terms of improving the github experience.
(In reply to Botond Ballo [:botond] from comment #0)
(Though sometimes commit messages reference issue numbers which go to
https://github.com/llvm/llvm-project/issue/XXXXX; not sure if there's a way to do an either/or.)
Hm, yeah, my naive searching is not finding a public endpoint that can automatically bounce to the right type. The GitHub docs on CORS indicate a cross-origin fetch would be accepted; the main caveat is the rate limit of 60 unauthenticated requests per hour. A reasonable complexity trade-off could be to add a helper method to our JS logic for ambiguous issue/PR numbers that could preventDefault on the link click, perform the resolution, and then try and carry-through on the link click. Given the rate limiting and wanting to be good citizens, I don't think we could prefetch. Also, there might be an uncanny valley for people who like to use middle-click, although maybe we can make that work.
The more involved alternative would be to have searchfox do something like sync the github issues/pull requests to a local cache as part of the update process. The issues API for example supports a "since" query which could allow for replication of this state. This could make sense as a broader set of features to make bug/pull request references more first class, including potentially exposing them to the cross-reference mechanism. The most practical upside might be the ability to show the bug subject on hover via use of a "title" attribute.
For performance, consistency, and reliability reasons I think categorically we would not want output.rs attempting to perform any lookups dynamically, at least as long as it runs in an "embarassingly parallel" fashion and is stateless.
|
||
Comment 2•1 year ago
|
||
my naive searching is not finding a public endpoint that can automatically bounce to the right type
Both https://github.com/org/repo/issues/XXXXXX and https://github.com/org/repo/pull/XXXXXX redirect to the right kind when needed.
For instance for the LLVM PR 69283 mentioned above, linking to https://github.com/llvm/llvm-project/issues/69283 works just fine.
Description
•