Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* [patch] useless code in symtab.c
@ 2002-10-23 15:27 David Carlton
  2002-10-23 15:35 ` Elena Zannoni
  0 siblings, 1 reply; 8+ messages in thread
From: David Carlton @ 2002-10-23 15:27 UTC (permalink / raw)
  To: gdb-patches; +Cc: Elena Zannoni, Jim Blandy

In my eternal quest to understand symtab.c, I found an unnecessary
declaration and a function that is never called; here's a patch to
delete them.  I have no idea what was up with the
find_template_name_end declaration, but nobody in symtab.c calls it
any more; and cplusplus_hint's functionality has been moved into
cplusplus_error.

No new regressions.  This patch seems obvious; I'll commit it in a
couple of days unless somebody complains.

David Carlton
carlton@math.stanford.edu

2002-10-23  David Carlton  <carlton@math.stanford.edu>

	* symtab.c: Delete cplusplus_hint.
	Delete prototype for find_template_name_end.

Index: symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.70
diff -u -p -r1.70 symtab.c
--- symtab.c	20 Sep 2002 14:58:58 -0000	1.70
+++ symtab.c	23 Oct 2002 21:04:54 -0000
@@ -50,11 +50,6 @@
 #include <ctype.h>
 #include "cp-abi.h"
 
-/* Prototype for one function in parser-defs.h,
-   instead of including that entire file. */
-
-extern char *find_template_name_end (char *);
-
 /* Prototypes for local functions */
 
 static void completion_list_add_name (char *, char *, int, char *, char *);
@@ -120,19 +115,6 @@ struct type *builtin_type_error;
    value_of_this. */
 
 const struct block *block_found;
-
-/* While the C++ support is still in flux, issue a possibly helpful hint on
-   using the new command completion feature on single quoted demangled C++
-   symbols.  Remove when loose ends are cleaned up.   FIXME -fnf */
-
-static void
-cplusplus_hint (char *name)
-{
-  while (*name == '\'')
-    name++;
-  printf_filtered ("Hint: try '%s<TAB> or '%s<ESC-?>\n", name, name);
-  printf_filtered ("(Note leading single quote.)\n");
-}
 
 /* Check for a symtab of a specific name; first in symtabs, then in
    psymtabs.  *If* there is no '/' in the name, a match after a '/'


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [patch] useless code in symtab.c
  2002-10-23 15:27 [patch] useless code in symtab.c David Carlton
@ 2002-10-23 15:35 ` Elena Zannoni
  2002-10-23 15:43   ` David Carlton
  0 siblings, 1 reply; 8+ messages in thread
From: Elena Zannoni @ 2002-10-23 15:35 UTC (permalink / raw)
  To: David Carlton; +Cc: gdb-patches, Elena Zannoni, Jim Blandy

David Carlton writes:
 > In my eternal quest to understand symtab.c, I found an unnecessary
 > declaration and a function that is never called; here's a patch to
 > delete them.  I have no idea what was up with the
 > find_template_name_end declaration, but nobody in symtab.c calls it
 > any more; and cplusplus_hint's functionality has been moved into
 > cplusplus_error.
 > 

that's a coincidence, I was just looking at this code myself, and wondering.

 > No new regressions.  This patch seems obvious; I'll commit it in a
 > couple of days unless somebody complains.
 > 

yes. Can you also knock out the one at:

linespec.c:38:extern char *find_template_name_end (char *);

Thanks
Elena


 > David Carlton
 > carlton@math.stanford.edu
 > 
 > 2002-10-23  David Carlton  <carlton@math.stanford.edu>
 > 
 > 	* symtab.c: Delete cplusplus_hint.
 > 	Delete prototype for find_template_name_end.
 > 
 > Index: symtab.c
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/symtab.c,v
 > retrieving revision 1.70
 > diff -u -p -r1.70 symtab.c
 > --- symtab.c	20 Sep 2002 14:58:58 -0000	1.70
 > +++ symtab.c	23 Oct 2002 21:04:54 -0000
 > @@ -50,11 +50,6 @@
 >  #include <ctype.h>
 >  #include "cp-abi.h"
 >  
 > -/* Prototype for one function in parser-defs.h,
 > -   instead of including that entire file. */
 > -
 > -extern char *find_template_name_end (char *);
 > -
 >  /* Prototypes for local functions */
 >  
 >  static void completion_list_add_name (char *, char *, int, char *, char *);
 > @@ -120,19 +115,6 @@ struct type *builtin_type_error;
 >     value_of_this. */
 >  
 >  const struct block *block_found;
 > -
 > -/* While the C++ support is still in flux, issue a possibly helpful hint on
 > -   using the new command completion feature on single quoted demangled C++
 > -   symbols.  Remove when loose ends are cleaned up.   FIXME -fnf */
 > -
 > -static void
 > -cplusplus_hint (char *name)
 > -{
 > -  while (*name == '\'')
 > -    name++;
 > -  printf_filtered ("Hint: try '%s<TAB> or '%s<ESC-?>\n", name, name);
 > -  printf_filtered ("(Note leading single quote.)\n");
 > -}
 >  
 >  /* Check for a symtab of a specific name; first in symtabs, then in
 >     psymtabs.  *If* there is no '/' in the name, a match after a '/'


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [patch] useless code in symtab.c
  2002-10-23 15:35 ` Elena Zannoni
@ 2002-10-23 15:43   ` David Carlton
  2002-10-23 15:57     ` Elena Zannoni
  0 siblings, 1 reply; 8+ messages in thread
From: David Carlton @ 2002-10-23 15:43 UTC (permalink / raw)
  To: Elena Zannoni; +Cc: gdb-patches, Jim Blandy

On Wed, 23 Oct 2002 18:32:32 -0400, Elena Zannoni <ezannoni@redhat.com> said:

> Can you also knock out the one at:

> linespec.c:38:extern char *find_template_name_end (char *);

That one gets used by decode_line_1.  (One of these days, I'll try to
understand what that function is doing, but I'm not feeling quite that
masochistic yet.)  Though I don't see any compelling reason not to
just #include "parser-defs.h" there instead of declaring that one
function specially; should I go ahead and do that?

(Looking through ChangeLogs, I see that code in linespec.c used to be
in symtab.c; that explains why the prototype was in symtab.c.)

David Carlton
carlton@math.stanford.edu


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [patch] useless code in symtab.c
  2002-10-23 15:43   ` David Carlton
@ 2002-10-23 15:57     ` Elena Zannoni
  2002-10-23 16:29       ` David Carlton
  0 siblings, 1 reply; 8+ messages in thread
From: Elena Zannoni @ 2002-10-23 15:57 UTC (permalink / raw)
  To: David Carlton; +Cc: Elena Zannoni, gdb-patches, Jim Blandy

David Carlton writes:
 > On Wed, 23 Oct 2002 18:32:32 -0400, Elena Zannoni <ezannoni@redhat.com> said:
 > 
 > > Can you also knock out the one at:
 > 
 > > linespec.c:38:extern char *find_template_name_end (char *);
 > 
 > That one gets used by decode_line_1.  (One of these days, I'll try to
 > understand what that function is doing, but I'm not feeling quite that
 > masochistic yet.)  Though I don't see any compelling reason not to
 > just #include "parser-defs.h" there instead of declaring that one
 > function specially; should I go ahead and do that?
 > 

decode_line_1, I think it will also make coffee if you ask nicely.... :-(

Yes, please, and update the Makefile.in dependencies.

 > (Looking through ChangeLogs, I see that code in linespec.c used to be
 > in symtab.c; that explains why the prototype was in symtab.c.)
 > 

yes, Fernando split the two.

Elena

 > David Carlton
 > carlton@math.stanford.edu


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [patch] useless code in symtab.c
  2002-10-23 15:57     ` Elena Zannoni
@ 2002-10-23 16:29       ` David Carlton
  2002-10-23 16:36         ` Daniel Jacobowitz
  2002-10-23 17:20         ` Elena Zannoni
  0 siblings, 2 replies; 8+ messages in thread
From: David Carlton @ 2002-10-23 16:29 UTC (permalink / raw)
  To: Elena Zannoni; +Cc: gdb-patches, Jim Blandy

On Wed, 23 Oct 2002 18:54:13 -0400, Elena Zannoni <ezannoni@redhat.com> said:

> David Carlton writes:
>> On Wed, 23 Oct 2002 18:32:32 -0400, Elena Zannoni <ezannoni@redhat.com> said:

>>> Can you also knock out the one at:

>>> linespec.c:38:extern char *find_template_name_end (char *);

>> That one gets used by decode_line_1.  (One of these days, I'll try
>> to understand what that function is doing, but I'm not feeling
>> quite that masochistic yet.)  Though I don't see any compelling
>> reason not to just #include "parser-defs.h" there instead of
>> declaring that one function specially; should I go ahead and do
>> that?

> decode_line_1, I think it will also make coffee if you ask
> nicely.... :-(

I really will have to give it a look; refactoring lookup_symbol_aux
was fairly pleasant and has turned out to be quite useful for me, so
at some point I'll see if decode_line_1 is amenable to a similar
treament.  Probably not, though: lookup_symbol_aux breaks fairly
neatly into a few decent-sized chunks, whereas decode_line_1 is a good
deal longer (770 lines as opposed to 370) and seems to me, upon a
brief skim, to not want to break apart nearly as nicely.

Incidentally, have you looked over the lookup_symbol_aux refactoring
yet?  (At
<http://sources.redhat.com/ml/gdb-patches/2002-10/msg00080.html>.)
It's not particularly urgent yet, but at some point I'm going to need
to need to get some sort of consensus as to what it means to look
something up in the global symbol table, and that patch is a good
starting place for discussion.  I think it's all a good idea except
maybe I shouldn't move the partial symbol table lookup before the
minimal symbol table lookup just yet.

> Yes, please, and update the Makefile.in dependencies.

Great, will do.

David Carlton
carlton@math.stanford.edu


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [patch] useless code in symtab.c
  2002-10-23 16:29       ` David Carlton
@ 2002-10-23 16:36         ` Daniel Jacobowitz
  2002-10-23 17:20         ` Elena Zannoni
  1 sibling, 0 replies; 8+ messages in thread
From: Daniel Jacobowitz @ 2002-10-23 16:36 UTC (permalink / raw)
  To: gdb-patches

On Wed, Oct 23, 2002 at 04:29:05PM -0700, David Carlton wrote:
> On Wed, 23 Oct 2002 18:54:13 -0400, Elena Zannoni <ezannoni@redhat.com> said:
> 
> > David Carlton writes:
> >> On Wed, 23 Oct 2002 18:32:32 -0400, Elena Zannoni <ezannoni@redhat.com> said:
> 
> >>> Can you also knock out the one at:
> 
> >>> linespec.c:38:extern char *find_template_name_end (char *);
> 
> >> That one gets used by decode_line_1.  (One of these days, I'll try
> >> to understand what that function is doing, but I'm not feeling
> >> quite that masochistic yet.)  Though I don't see any compelling
> >> reason not to just #include "parser-defs.h" there instead of
> >> declaring that one function specially; should I go ahead and do
> >> that?
> 
> > decode_line_1, I think it will also make coffee if you ask
> > nicely.... :-(
> 
> I really will have to give it a look; refactoring lookup_symbol_aux
> was fairly pleasant and has turned out to be quite useful for me, so
> at some point I'll see if decode_line_1 is amenable to a similar
> treament.  Probably not, though: lookup_symbol_aux breaks fairly
> neatly into a few decent-sized chunks, whereas decode_line_1 is a good
> deal longer (770 lines as opposed to 370) and seems to me, upon a
> brief skim, to not want to break apart nearly as nicely.

I admit (blasphemy!) I'm strongly considering declaring it dead, and
rewriting it to meet a proper specification.  This means coming up with
one first though, so it's a little bit down my list.


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [patch] useless code in symtab.c
  2002-10-23 16:29       ` David Carlton
  2002-10-23 16:36         ` Daniel Jacobowitz
@ 2002-10-23 17:20         ` Elena Zannoni
  2002-10-23 17:25           ` David Carlton
  1 sibling, 1 reply; 8+ messages in thread
From: Elena Zannoni @ 2002-10-23 17:20 UTC (permalink / raw)
  To: David Carlton; +Cc: Elena Zannoni, gdb-patches, Jim Blandy

David Carlton writes:
 > 
 > Incidentally, have you looked over the lookup_symbol_aux refactoring
 > yet?  (At
 > <http://sources.redhat.com/ml/gdb-patches/2002-10/msg00080.html>.)
 > It's not particularly urgent yet, but at some point I'm going to need
 > to need to get some sort of consensus as to what it means to look
 > something up in the global symbol table, and that patch is a good
 > starting place for discussion.  I think it's all a good idea except
 > maybe I shouldn't move the partial symbol table lookup before the
 > minimal symbol table lookup just yet.
 > 

Sigh, not yet. I want to finish helping Keith merging his MI branch,
then I'll look at the symbol table branches.
I hope next week.

Elena


 > > Yes, please, and update the Makefile.in dependencies.
 > 
 > Great, will do.
 > 
 > David Carlton
 > carlton@math.stanford.edu


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [patch] useless code in symtab.c
  2002-10-23 17:20         ` Elena Zannoni
@ 2002-10-23 17:25           ` David Carlton
  0 siblings, 0 replies; 8+ messages in thread
From: David Carlton @ 2002-10-23 17:25 UTC (permalink / raw)
  To: Elena Zannoni; +Cc: gdb-patches, Jim Blandy

On Wed, 23 Oct 2002 20:18:05 -0400, Elena Zannoni <ezannoni@redhat.com> said:
> David Carlton writes:

>> Incidentally, have you looked over the lookup_symbol_aux refactoring
>> yet?

> Sigh, not yet. I want to finish helping Keith merging his MI branch,
> then I'll look at the symbol table branches.  I hope next week.

Thanks.  Like I said, it's nothing too urgent: by all means, spend
your time on patches that actually make GDB work better instead of
patches that just move code from one place to another.

I've changed linespec.c and Makefile.in as you requested.

David Carlton
carlton@math.stanford.edu


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2002-10-24  0:25 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-10-23 15:27 [patch] useless code in symtab.c David Carlton
2002-10-23 15:35 ` Elena Zannoni
2002-10-23 15:43   ` David Carlton
2002-10-23 15:57     ` Elena Zannoni
2002-10-23 16:29       ` David Carlton
2002-10-23 16:36         ` Daniel Jacobowitz
2002-10-23 17:20         ` Elena Zannoni
2002-10-23 17:25           ` David Carlton

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox