public inbox for sourcenav@sourceware.org
 help / color / mirror / Atom feed
From: Mo DeJong <mdejong@cygnus.com>
To: sourcenav@sources.redhat.com
Subject: Re: xref and referred by?
Date: Thu, 19 Oct 2000 22:08:00 -0000	[thread overview]
Message-ID: <Pine.SOL.3.91.1001019220539.24819A-100000@cse.cygnus.com> (raw)
In-Reply-To: <C125697D.0036F94F.00@mz02world.hq.dtr.gecalsthom.fr>

On Thu, 19 Oct 2000 dave.banham@tde.alstom.com wrote:
 
> My project is 100% (embedded) C code and I still have problems with xref. I hope
> that when the C++ parser is fixed that the C parsing capabilities will be
> improved too.
> 
> BTW, I notice that sometimes when I right click on a variable in the editor
> window and select Find Implementation of 'xyz' that nothing happens, but when I
> select Find Declaration of 'xyz' SN puts up a window asking me choose one of two
> files to view. The first file is always a .h file and when selected it shows a
> line with the variable declared extern. Whilst the second file is the .c and
> shows the line where the variable is implemented (or is that declared?) If I
> then click on the variable's declared type (which is a typedef'd type), Find
> Implementation does nothing and Find Declaration switches (correctly) to the
> file containing the typedef statement for the type. If I now repeat this for the
> type name (in the typedef statement), Find Implementation does nothing and Find
> Declaration highlights the type name. Using Xref on the type name, shows that
> xref doesn't know where the type is used either.
> 
> Oddly enough, Find Implementation and Find Declaration work fine for function
> names, as does Xref. Is the cross-reference information broken for variables and
> types or was it never intended to cover variables and types? (If so why not?)
> 
> Regards
> Dave Banham

If you could create a small test case that reproduces this
error, that would really help. Without a way to reproduce
the error, we are not going to be able to fix it. Oh, and
please don't include things like, "download mozilla and
then do this ...". That does not help, we need a test
case with one or two functions that shows the error.

Mo DeJong
Red Hat Inc

  parent reply	other threads:[~2000-10-19 22:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-10-19  3:01 dave.banham
2000-10-19  7:58 ` Berek
2000-10-19 22:08 ` Mo DeJong [this message]
  -- strict thread matches above, loose matches on Subject: below --
2000-11-15  4:57 dave.banham
2000-11-14  8:55 Mark Thornber
2000-10-18  1:11 dave.banham
2000-10-17  8:36 Lonnie L VanZandt
2000-10-17  8:45 ` Bruce Stephens

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.SOL.3.91.1001019220539.24819A-100000@cse.cygnus.com \
    --to=mdejong@cygnus.com \
    --cc=sourcenav@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).