From: Keith Seitz <keiths@redhat.com>
To: gdb-patches@sourceware.org
Subject: [RFC] Special casing dtors?
Date: Wed, 25 Mar 2009 22:39:00 -0000 [thread overview]
Message-ID: <49CAB139.8010100@redhat.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1140 bytes --]
Hi,
I've been looking a bit at a patch (in Fedora) which fixes prms/1112,
and I notice that both valops.c and linespec.c treat destructors as
"special case"s -- but nowhere does it say WHY.
I've searched through all the history I can find about this (including
the Cygnus internal ueberbaum), and all I've been able to discover is
that this has been in a LONG time (before 1990).
So out of curiosity, I removed all those special cases, and lo! There
were no new failures, and one new pass in the testsuite (on x86, CVS HEAD).
Can anyone explain to me either why gdb treats dtors differently from
"normal" methods or why we shouldn't commit something like the attached
patch?
Keith
ChangeLog
2009-03-25 Keith Seitz <keiths@redhat.com>
* linespec.c (collect_methods): Delete.
(add_matching_methods): Reove destructor special case.
(find_method): Call find_methods directly instead of
collect_methods.
* valops.c (value_struct_elt): Remove destructor
special cases.
(check_field): Likewise.
(value_struct_elt_for_reference): Likewise.
(destructor_name_p): Remove misleading comment about dtors
being "special cases".
[-- Attachment #2: dtor-special-case.patch --]
[-- Type: text/plain, Size: 4863 bytes --]
Index: linespec.c
===================================================================
RCS file: /cvs/src/src/gdb/linespec.c,v
retrieving revision 1.84
diff -u -p -r1.84 linespec.c
--- linespec.c 3 Jan 2009 05:57:52 -0000 1.84
+++ linespec.c 25 Mar 2009 22:28:08 -0000
@@ -76,10 +76,6 @@ static struct symtabs_and_lines find_met
struct type *t,
struct symbol *sym_class);
-static int collect_methods (char *copy, struct type *t,
- struct symbol *sym_class,
- struct symbol **sym_arr);
-
static NORETURN void cplusplus_error (const char *name,
const char *fmt, ...)
ATTR_NORETURN ATTR_FORMAT (printf, 2, 3);
@@ -306,11 +302,6 @@ add_matching_methods (int method_counter
else
phys_name = TYPE_FN_FIELD_PHYSNAME (f, field_counter);
- /* Destructor is handled by caller, don't add it to
- the list. */
- if (is_destructor_name (phys_name) != 0)
- continue;
-
sym_arr[i1] = lookup_symbol_in_language (phys_name,
NULL, VAR_DOMAIN,
language,
@@ -1441,7 +1432,7 @@ find_method (int funfirstline, char ***c
/* Find all methods with a matching name, and put them in
sym_arr. */
- i1 = collect_methods (copy, t, sym_class, sym_arr);
+ i1 = find_methods (t, copy, SYMBOL_LANGUAGE (sym_class), sym_arr);
if (i1 == 1)
{
@@ -1492,37 +1483,6 @@ find_method (int funfirstline, char ***c
}
}
-/* Find all methods named COPY in the class whose type is T, and put
- them in SYM_ARR. Return the number of methods found. */
-
-static int
-collect_methods (char *copy, struct type *t,
- struct symbol *sym_class, struct symbol **sym_arr)
-{
- int i1 = 0; /* Counter for the symbol array. */
-
- if (destructor_name_p (copy, t))
- {
- /* Destructors are a special case. */
- int m_index, f_index;
-
- if (get_destructor_fn_field (t, &m_index, &f_index))
- {
- struct fn_field *f = TYPE_FN_FIELDLIST1 (t, m_index);
-
- sym_arr[i1] =
- lookup_symbol (TYPE_FN_FIELD_PHYSNAME (f, f_index),
- NULL, VAR_DOMAIN, (int *) NULL);
- if (sym_arr[i1])
- i1++;
- }
- }
- else
- i1 = find_methods (t, copy, SYMBOL_LANGUAGE (sym_class), sym_arr);
-
- return i1;
-}
-
\f
/* Return the symtab associated to the filename given by the substring
Index: valops.c
===================================================================
RCS file: /cvs/src/src/gdb/valops.c,v
retrieving revision 1.210
diff -u -p -r1.210 valops.c
--- valops.c 20 Mar 2009 23:04:34 -0000 1.210
+++ valops.c 25 Mar 2009 22:28:09 -0000
@@ -1858,10 +1858,6 @@ value_struct_elt (struct value **argp, s
/* C++: If it was not found as a data field, then try to
return it as a pointer to a method. */
-
- if (destructor_name_p (name, t))
- error (_("Cannot get value of destructor"));
-
v = search_struct_method (name, argp, args, 0,
static_memfuncp, t);
@@ -1877,32 +1873,6 @@ value_struct_elt (struct value **argp, s
return v;
}
- if (destructor_name_p (name, t))
- {
- if (!args[1])
- {
- /* Destructors are a special case. */
- int m_index, f_index;
-
- v = NULL;
- if (get_destructor_fn_field (t, &m_index, &f_index))
- {
- v = value_fn_field (NULL,
- TYPE_FN_FIELDLIST1 (t, m_index),
- f_index, NULL, 0);
- }
- if (v == NULL)
- error (_("could not find destructor function named %s."),
- name);
- else
- return v;
- }
- else
- {
- error (_("destructor should not have any argument"));
- }
- }
- else
v = search_struct_method (name, argp, args, 0,
static_memfuncp, t);
@@ -2508,8 +2478,6 @@ classify_oload_match (struct badness_vec
int
destructor_name_p (const char *name, const struct type *type)
{
- /* Destructors are a special case. */
-
if (name[0] == '~')
{
char *dname = type_name_no_tag (type);
@@ -2548,14 +2516,6 @@ check_field (struct type *type, const ch
/* C++: If it was not found as a data field, then try to return it
as a pointer to a method. */
- /* Destructors are a special case. */
- if (destructor_name_p (name, type))
- {
- int m_index, f_index;
-
- return get_destructor_fn_field (type, &m_index, &f_index);
- }
-
for (i = TYPE_NFN_FIELDS (type) - 1; i >= 0; --i)
{
if (strcmp_iw (TYPE_FN_FIELDLIST_NAME (type, i), name) == 0)
@@ -2651,12 +2611,6 @@ value_struct_elt_for_reference (struct t
/* C++: If it was not found as a data field, then try to return it
as a pointer to a method. */
- /* Destructors are a special case. */
- if (destructor_name_p (name, t))
- {
- error (_("member pointers to destructors not implemented yet"));
- }
-
/* Perform all necessary dereferencing. */
while (intype && TYPE_CODE (intype) == TYPE_CODE_PTR)
intype = TYPE_TARGET_TYPE (intype);
next reply other threads:[~2009-03-25 22:33 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-25 22:39 Keith Seitz [this message]
2009-03-26 22:07 ` Tom Tromey
2009-03-26 22:39 ` Stan Shebs
2009-03-27 2:35 ` Daniel Jacobowitz
2009-03-27 8:07 ` Keith Seitz
2009-03-27 15:06 ` Pedro Alves
2009-03-27 15:41 ` Joel Brobecker
2009-03-27 17:19 ` Keith Seitz
2009-03-27 17:49 ` Pedro Alves
2009-03-27 19:05 ` Keith Seitz
2009-03-27 19:22 ` Pedro Alves
2009-03-28 0:56 ` Keith Seitz
2009-03-28 8:56 ` Keith Seitz
2009-03-30 21:46 ` Pedro Alves
2009-04-01 23:48 ` Keith Seitz
2009-04-02 3:17 ` Daniel Jacobowitz
2009-04-02 16:25 ` Keith Seitz
2009-04-02 16:32 ` Daniel Jacobowitz
2009-04-02 8:27 ` Mark Kettenis
2009-04-07 20:54 ` Pedro Alves
2009-04-07 21:26 ` Keith Seitz
2009-04-24 6:06 ` Tom Tromey
2009-04-24 17:54 ` Keith Seitz
2009-04-24 22:49 ` Tom Tromey
2009-06-16 18:41 ` Keith Seitz
2009-03-28 21:19 ` Tom Tromey
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=49CAB139.8010100@redhat.com \
--to=keiths@redhat.com \
--cc=gdb-patches@sourceware.org \
/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