Make #include statements clickable
Categories
(Webtools :: Searchfox, enhancement)
Tracking
(Not tracked)
People
(Reporter: kats, Assigned: kats)
References
(Blocks 1 open bug)
Details
Attachments
(3 files)
|
Assignee | |
Comment 1•4 years ago
|
||
There's a function on the PPCallbacks interface which might be useful in implementing this: https://searchfox.org/llvm/rev/c0cdd22c72fab47a3c37b5a8401763995cadaa77/clang/include/clang/Lex/PPCallbacks.h#122-131
Presumably we can implement this in our clang-plugin implementation and have it emit info that the indexer can then use to linkify.
|
|
Assignee | |
Comment 2•4 years ago
|
||
I have some related work in bug 1673090 that I can partially reuse to do this. I'll take a look at some point.
|
|
Assignee | |
Updated•4 years ago
|
|
|
Assignee | |
Comment 3•4 years ago
|
||
This extracts a relativizePath function that normalizes a file path to be
relative to the source/objdir, and returns the type of the file.
|
|
Assignee | |
Comment 4•4 years ago
|
||
In the next patch I'll want to be able to provide the entire source rather than
having visitIdentifier just use the token at Loc. The existing call sites
create a SourceRange from the SourceLocation and indicate (by not setting the
LocRangeEndValid flag) that the visitIdentifier function should retain it's
old behaviour of using the token to figure out the range.
Depends on D95527
|
|
Assignee | |
Comment 5•4 years ago
|
||
This introduces a new mangled symbol of the form FILE_<hash>. It's defined
on line 1 of each visited source file, and it's referenced in places that
the preprocessor tells us there was an #include. Both angle-bracket includes
and quote includes are supported here.
Depends on D95528
|
|
Assignee | |
Comment 6•4 years ago
|
||
The patches above generate the analysis data for file linkages. There's one small piece required on the rust side to actually hook it up, for includes of the type #include "some/file". For includes of the type #include <some/file> (i.e. using angle brackets) it's a bit more complicated, because the <some/file> bit corresponds to multiple tokens, some of which are punctuation and such. While looking into how to hook that up I also realized that currently if we have an overloaded operator== for example, we don't provide semantic lookup for that at the use site, because it's treated as puncutation. So there's a few changes needed to make these use cases work, and I'm going to spin those off into a separate bug.
|
||
Comment 7•4 years ago
|
||
I just tried this on https://kats.searchfox.org/ and this is 2 amazing work-flow improvements. I expect to use the "go to definition" feature all the time, but I think the "search for file" mechanism will also be invaluable in finding inclusions without getting overwhelmed by text-search matches that have different semantics. Thank you, and looking forward to seeing this landed!
|
|
Assignee | |
Comment 8•4 years ago
|
||
|
||
Comment 10•4 years ago
|
||
| bugherder | ||
|
|
Assignee | |
Comment 11•4 years ago
|
||
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #6)
While looking into how to hook that up I also realized that currently if we have an overloaded
operator==for example, we don't provide semantic lookup for that at the use site, because it's treated as puncutation. So there's a few changes needed to make these use cases work, and I'm going to spin those off into a separate bug.
Filed bug 1675264 for this
|
|
Assignee | |
Comment 12•4 years ago
|
||
Quick followup for some tests: https://github.com/mozsearch/mozsearch/pull/387
|
|
Assignee | |
Updated•4 years ago
|
Description
•