GNU bug report logs -
#78221
31.0.50; Improving *-change-functions notifications
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
On Sun, May 4, 2025, 19:12 Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
> >> The right tool to find these is cflow, combined with grep and awk (or
> >> python or perl or whatever) to search and filter cflow's output. I've
> >> used these before.
> >
> > Do you happen to remember the magic incantation to let `cflow` process
> > our sources correctly? I tried the rule below and the errors file
> > suggests that the preprocessing is done correctly (it's full of
> > complaints but only about redefinitions), yet the result doesn't include
> > any info about the functions called by `insert_1_both` or
> > `Fput_text_property` (to take two randomly sampled cases of interest).
>
> I use Clangd + Eglot + eglot-supplements if I have questions about who
> call whom.
>
> With clangd 20 one can display incoming and outgoing call trees. Only
> inconvenience is that one has to expand nodes in the tree manually
> because nodes are created on demand via LSP. And this of course only
> sees what's compiled in.
>
I was going to suggest mostly the and, except you don't need "eglot
supplements" since call hierarchies (and type, too) are blue in Eglot for
some months. See the manual of you're interested.
I clangd sees anything that compile_commands.json mentions, it doesn't
actually need to be or have been compiled.
Expanding node by node makes sense to me, as huge swaths of the graph
(which is sometimes cyclic) are uninteresting.
João
>
[Message part 2 (text/html, inline)]
This bug report was last modified 32 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.