Closed Bug 1418001 Opened 7 years ago Closed 4 years ago

Make #include statements clickable

Categories

(Webtools :: Searchfox, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: kats, Assigned: kats)

References

(Blocks 1 open bug)

Details

Attachments

(3 files)

Oftentimes there's an #include "somefile.h" and I'd like to be able to click on the "somefile.h" to go to that file. Assuming that header is in the set of files that searchfox has indexed, of course.

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.

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: nobody → kats

This extracts a relativizePath function that normalizes a file path to be
relative to the source/objdir, and returns the type of the file.

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

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

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.

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!

Pushed by kgupta@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e18463026c87
Refactor to make file type detection more explicit. r=asuth,andi
https://hg.mozilla.org/integration/autoland/rev/568498daabe8
Refactor to allow visitIdentifier callers to pass a full SourceRange. r=asuth,andi
https://hg.mozilla.org/integration/autoland/rev/a06787957417
Generate analysis for file inclusions. r=asuth,andi

(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

Status: NEW → RESOLVED
Closed: 4 years ago
Keywords: leave-open
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: