Re: [patch] gdb.c++/local.exp: add pr numbers

Re: [patch] gdb.c++/local.exp: add pr numbers

[Michael Elizabeth Chastain]

Daniel Berlin writes:

I am going to hold off on my bug-referencing patches to gdb.c++/*.exp
while we have some discussion.

> Bugzilla bug ids for gnats bugs will be the same as they were for gnats.

Okay.

> Um, if you simply write something fitting the regex bug(\s|%\#)*(\d+) ,
> bugzilla will make it link to the bug in question.

That sounds mostly good to me.  (Right now I am really glad that I've
learned enough Perl to read those Perl regex's).

However, it looks like the "gdb" part is implicit, such as:

  bug %#277

I want to mark all the gdb bugs (KFAILs) with gdb bug numbers,
so that would work.  I also want to mark all the environment bugs (XFAILs)
with bug numbers for their corresponding systems.  How can I cite a gcc
bug number in a gdb XFAIL?

Similarly, if someone outside gdb wants to refer to a gdb bug,
then "bug %#277" is not quite enough context, because it doesn't specify
which bugzilla database it's talking about.  I'd like it better if there
were a form with the bugzilla database name in the string.

> I'm not going to modify the bugzilla source (to recognize any other
> citation forms, as this highlighting is done in a routine used all over
> the place (and thus, it's harder to verify a given regex does what you
> expect in all cases), and I am specifically trying to avoid making any
> changes to the perl source that can be avoided (the templates are
> expected to be changed).

Well, I think any coherent system is better than what we have now,
which is no information.  If I can mark all the KFAILs, and let the
XFAILs twist in the wind, I can live with that.

Michael C

Re: [patch] gdb.c++/local.exp: add pr numbers

[Daniel Berlin]

On Sun, 2002-04-14 at 02:40, Michael Elizabeth Chastain wrote:
> Daniel Berlin writes:
> 
> I am going to hold off on my bug-referencing patches to gdb.c++/*.exp
> while we have some discussion.
> 
> > Bugzilla bug ids for gnats bugs will be the same as they were for gnats.
> 
> Okay.
> 
> > Um, if you simply write something fitting the regex bug(\s|%\#)*(\d+) ,
> > bugzilla will make it link to the bug in question.
> 
> That sounds mostly good to me.  (Right now I am really glad that I've
> learned enough Perl to read those Perl regex's).

> 
> However, it looks like the "gdb" part is implicit, such as:
> 
>   bug %#277
> 
> I want to mark all the gdb bugs (KFAILs) with gdb bug numbers,
> so that would work.  I also want to mark all the environment bugs (XFAILs)
> with bug numbers for their corresponding systems.  How can I cite a gcc
> bug number in a gdb XFAIL?
> 
> Similarly, if someone outside gdb wants to refer to a gdb bug,
> then "bug %#277" is not quite enough context, because it doesn't specify
> which bugzilla database it's talking about.  I'd like it better if there
> were a form with the bugzilla database name in the string.
Ah, you are confused because gnats has different databases for different
products, while bugzilla supports multiple products in a single
database.
To be clear:
1. Bugzilla supports multiple products by default, in a single database.
(Each product can itself, have multiple components, as well)
2. Bug ids are unique within a given bugzilla database.

Thus, gdb bug numbers and gcc bug numbers will never conflict, once they
are in the same bugzilla system.

However, this *is* actually going to be annoying in the initial import,
since it means that if they share the same bugzilla system (which only
makes sense), i'll have to remap gdb's bug numbers to a new range (IE
add 10000 to them. There are almost exactly 7000 gcc bug reports, and
not going to be 3000 more before we switch)

Once the initial import is done, there will be no further problems,
since,as I said, bug numbers are unique to a given bugzilla database,
not to a given product in that database.

Think of it from the SQL database point of view.
(I'm simplifying, since comments/attachments are in a seperate table).
All bugs, for a given bugzilla installation are stored in a table, with
a primary key of the bug id.
The product is just another field on the bug.

> 
> > I'm not going to modify the bugzilla source (to recognize any other
> > citation forms, as this highlighting is done in a routine used all over
> > the place (and thus, it's harder to verify a given regex does what you
> > expect in all cases), and I am specifically trying to avoid making any
> > changes to the perl source that can be avoided (the templates are
> > expected to be changed).
> 
> Well, I think any coherent system is better than what we have now,
> which is no information.  If I can mark all the KFAILs, and let the
> XFAILs twist in the wind, I can live with that.
> 
> Michael C

Re: [patch] gdb.c++/local.exp: add pr numbers

[Andrew Cagney]

> 1. Bugzilla supports multiple products by default, in a single database.
> (Each product can itself, have multiple components, as well)
> 2. Bug ids are unique within a given bugzilla database.
> 
> Thus, gdb bug numbers and gcc bug numbers will never conflict, once they
> are in the same bugzilla system.

My understanding was that GDB was going to have a separate database.

Andrew

Re: [patch] gdb.c++/local.exp: add pr numbers

[Tom Tromey]

>>>>> "Dan" == Daniel Berlin <dberlin@dberlin.org> writes:

Dan> However, this *is* actually going to be annoying in the initial
Dan> import, since it means that if they share the same bugzilla
Dan> system (which only makes sense), i'll have to remap gdb's bug
Dan> numbers to a new range (IE add 10000 to them. There are almost
Dan> exactly 7000 gcc bug reports, and not going to be 3000 more
Dan> before we switch)

When we imported the libgcj Gnats database into the gcc database, we
had to renumber.  We just added a comment to every PR: "Previously PR
libgcj/OLD-NUMBER".  In the few situations where I've needed to look
up a PR by its old number, this has let me do it easily.

Tom

Re: [patch] gdb.c++/local.exp: add pr numbers

[Andrew Cagney]

> Daniel Berlin writes:
> 
> I am going to hold off on my bug-referencing patches to gdb.c++/*.exp
> while we have some discussion.
> 
> 
>> Bugzilla bug ids for gnats bugs will be the same as they were for gnats.
> 
> 
> Okay.
> 
> 
>> Um, if you simply write something fitting the regex bug(\s|%\#)*(\d+) ,
>> bugzilla will make it link to the bug in question.
> 
> 
> That sounds mostly good to me.  (Right now I am really glad that I've
> learned enough Perl to read those Perl regex's).
> 
> However, it looks like the "gdb" part is implicit, such as:
> 
>   bug %#277

Michael,

Can I suggest, for the moment, we stick with ``gdb/NNNN''.  If/when we 
switch to bugzilla these can be updated as needed.

enjoy,
Andrew

Re: [patch] gdb.c++/local.exp: add pr numbers

[Michael Elizabeth Chastain]

Committed.

Michael C

2002-04-22  Michael Chastain  <mec@shout.net>

	* gdb.c++/local.exp: Add PR numbers: gdb/482, gdb/483.

[patch] gdb.c++/local.exp: add pr numbers

[Michael Elizabeth Chastain]

This patch adds PR numbers to gdb.c++/local.exp.

Michael C

2002-04-22  Michael Chastain  <mec@shout.net>

	* gdb.c++/local.exp: Add PR numbers: gdb/482, gdb/483.

Index: gdb.c++/local.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.c++/local.exp,v
retrieving revision 1.7
diff -c -3 -p -r1.7 local.exp
*** gdb.c++/local.exp	10 Apr 2002 03:52:21 -0000	1.7
--- gdb.c++/local.exp	12 Apr 2002 22:25:33 -0000
*************** set sep "(\[.\]|___)\[0-9\]"
*** 101,107 ****
  send_gdb "ptype Local\n"
  gdb_expect {
    -re "type = class Local \{\[\r\n\t \]*public:\[\r\n\t \]*int loc1;\[\r\n\t \]*char loc_foo\\((const *|)char\\);\[\r\n\t \]*\}.*$gdb_prompt $" { pass "ptype Local" }
!   -re "type = class Local \{\[\r\n\t \]*public:\[\r\n\t \]*int loc1;\[\r\n\t \]*char loc_foo\\((const *|)char\\);\[\r\n\t \]*char loc_foo\\((const *|)char\\);\[\r\n\t \]*\}.*$gdb_prompt $" { fail "ptype Local (double loc_foo)" }
    -re "type = class Local \{\[\r\n\t \]*public:\[\r\n\t \]*int loc1;\[\r\n\t \]*Local & operator *=\\((foobar__Fi${sep}::|)Local const *&\\);\[\r\n\t \]*Local\\((foobar__Fi${sep}::|)Local const *&\\);\[\r\n\t \]*Local\\((void|)\\);\[\r\n\t \]*char loc_foo\\(char\\);\[\r\n\t \]*\}.*$gdb_prompt $" { pass "ptype Local" }
    -re "type = class Local \{\r\n\[\t \]*public:\r\n\[\t \]*int loc1;\r\n\r\n\[\t \]*char loc_foo\\(char\\);\r\n\[\t \]*\\(Local at.*local\\.cc:\[0-9\]*\\)\r\n\}.*$gdb_prompt $" { xpass "ptype Local (old aCC)" }
    -re ".*$gdb_prompt $"   {  fail "ptype Local" }
--- 101,110 ----
  send_gdb "ptype Local\n"
  gdb_expect {
    -re "type = class Local \{\[\r\n\t \]*public:\[\r\n\t \]*int loc1;\[\r\n\t \]*char loc_foo\\((const *|)char\\);\[\r\n\t \]*\}.*$gdb_prompt $" { pass "ptype Local" }
!   -re "type = class Local \{\[\r\n\t \]*public:\[\r\n\t \]*int loc1;\[\r\n\t \]*char loc_foo\\((const *|)char\\);\[\r\n\t \]*char loc_foo\\((const *|)char\\);\[\r\n\t \]*\}.*$gdb_prompt $" {
!     # setup_kfail "gdb/483"
!     fail "ptype Local (gdb/483)"
!   }
    -re "type = class Local \{\[\r\n\t \]*public:\[\r\n\t \]*int loc1;\[\r\n\t \]*Local & operator *=\\((foobar__Fi${sep}::|)Local const *&\\);\[\r\n\t \]*Local\\((foobar__Fi${sep}::|)Local const *&\\);\[\r\n\t \]*Local\\((void|)\\);\[\r\n\t \]*char loc_foo\\(char\\);\[\r\n\t \]*\}.*$gdb_prompt $" { pass "ptype Local" }
    -re "type = class Local \{\r\n\[\t \]*public:\r\n\[\t \]*int loc1;\r\n\r\n\[\t \]*char loc_foo\\(char\\);\r\n\[\t \]*\\(Local at.*local\\.cc:\[0-9\]*\\)\r\n\}.*$gdb_prompt $" { xpass "ptype Local (old aCC)" }
    -re ".*$gdb_prompt $"   {  fail "ptype Local" }
*************** send_gdb "ptype InnerLocal::NestedInnerL
*** 186,192 ****
  gdb_expect {
    -re "type = class InnerLocal::NestedInnerLocal \{\[\r\n\t \]*public:\[\r\n\t \]*int nil;\[\r\n\t \]*int nil_foo\\(int\\);\[\r\n\t \]*\}.*$gdb_prompt $" { pass "ptype InnerLocal::NestedInnerLocal" }
    -re "type = class InnerLocal::NestedInnerLocal \{\[\r\n\t \]*public:\[\r\n\t \]*int nil;\[\r\n\t \]*NestedInnerLocal *& *operator *= *\\((main${sep}::|)InnerLocal::NestedInnerLocal const *&\\);\[\r\n\t \]*NestedInnerLocal\\((main${sep}::|)InnerLocal::NestedInnerLocal const *&\\);\[\r\n\t \]*NestedInnerLocal\\((void|)\\);\[\r\n\t \]*int nil_foo\\(int\\);\[\r\n\t \]*\}.*$gdb_prompt $" { pass "ptype InnerLocal::NestedInnerLocal" }
!   -re "There is no field named NestedInnerLocal.*$gdb_prompt $" { fail "ptype InnerLocal::NestedInnerLocal (bogus field lookup)" }
    -re "No symbol .*NestedInnerLocal.* in current context.*$gdb_prompt $" { fail "ptype InnerLocal::NestedInnerLocal (bogus symbol lookup)" }
    -re ".*$gdb_prompt $"   {  fail "ptype InnerLocal::NestedInnerLocal" }
    timeout             { fail "(timeout) ptype InnerLocal::NestedInnerLocal" }
--- 189,198 ----
  gdb_expect {
    -re "type = class InnerLocal::NestedInnerLocal \{\[\r\n\t \]*public:\[\r\n\t \]*int nil;\[\r\n\t \]*int nil_foo\\(int\\);\[\r\n\t \]*\}.*$gdb_prompt $" { pass "ptype InnerLocal::NestedInnerLocal" }
    -re "type = class InnerLocal::NestedInnerLocal \{\[\r\n\t \]*public:\[\r\n\t \]*int nil;\[\r\n\t \]*NestedInnerLocal *& *operator *= *\\((main${sep}::|)InnerLocal::NestedInnerLocal const *&\\);\[\r\n\t \]*NestedInnerLocal\\((main${sep}::|)InnerLocal::NestedInnerLocal const *&\\);\[\r\n\t \]*NestedInnerLocal\\((void|)\\);\[\r\n\t \]*int nil_foo\\(int\\);\[\r\n\t \]*\}.*$gdb_prompt $" { pass "ptype InnerLocal::NestedInnerLocal" }
!   -re "There is no field named NestedInnerLocal.*$gdb_prompt $" {
!     # setup_kfail "gdb/482"
!     fail "ptype InnerLocal::NestedInnerLocal (gdb/482)"
!   }
    -re "No symbol .*NestedInnerLocal.* in current context.*$gdb_prompt $" { fail "ptype InnerLocal::NestedInnerLocal (bogus symbol lookup)" }
    -re ".*$gdb_prompt $"   {  fail "ptype InnerLocal::NestedInnerLocal" }
    timeout             { fail "(timeout) ptype InnerLocal::NestedInnerLocal" }

Re: [patch] gdb.c++/local.exp: add pr numbers

[Michael Elizabeth Chastain]

Andrew Cagney writes:
> Can I suggest, for the moment, we stick with ``gdb/NNNN''.  If/when we 
> switch to bugzilla these can be updated as needed.

Mmmm ... okay.

Michael C

Re: [patch] gdb.c++/local.exp: add pr numbers

[Michael Elizabeth Chastain]

Daniel Berlin writes:

  1. Bugzilla supports multiple products by default, in a single database.
  (Each product can itself, have multiple components, as well)
  2. Bug ids are unique within a given bugzilla database.

Ah.  Ok.  So this covers the case that I care about the most, which is
referring to gcc bugs.  As far as I know, gcc (broadly speaking, the
whole "gnu compiler collection") are the only Free Software compilers
supported by gdb.  Although maybe my knowledge is limited?

> However, this *is* actually going to be annoying in the initial import,
> since it means that if they share the same bugzilla system (which only
> makes sense), i'll have to remap gdb's bug numbers to a new range (IE
> add 10000 to them. There are almost exactly 7000 gcc bug reports, and
> not going to be 3000 more before we switch)

So gnats bug #277 is going to become bugzilla bug #10277, for instance?

Michael C

Re: [patch] gdb.c++/local.exp: add pr numbers

[Michael Elizabeth Chastain]

Andrew Cagney writes:
> Suggest just ``(gdb/482)''.  It appears GCC really is switching to 
> Bugzilla so ``gnats'' may one day not apply.

I thought about that.  When we switch to Bugzilla, is the bug still
going to be #482?  I like "gnats:gdb/482" because it identifies the bug
reporting system that actually contains the bug.

I don't know if there's a standard way of citing bug reports ...
do you want to promulgate one?

Michael C

Re: [patch] gdb.c++/local.exp: add pr numbers

[Daniel Berlin]

On Sat, 2002-04-13 at 18:06, Michael Elizabeth Chastain wrote:
> Andrew Cagney writes:
> > Suggest just ``(gdb/482)''.  It appears GCC really is switching to 
> > Bugzilla so ``gnats'' may one day not apply.
> 
> I thought about that.  When we switch to Bugzilla, is the bug still
> going to be #482? 
Yes.
Bugzilla bug ids for gnats bugs will be the same as they were for gnats.

> I like "gnats:gdb/482" because it identifies the bug
> reporting system that actually contains the bug.


> 
> I don't know if there's a standard way of citing bug reports ...
> do you want to promulgate one?

Um, if you simply write something fitting the regex bug(\s|%\#)*(\d+) ,
bugzilla will make it link to the bug in question.

If you want to reference a comment in the same bug, simply writing
something fitting comment(\s|%\#)*(\d+) will link to that comment

And combining the two, with an optional comma 
     bug(\s|%\#)*(\d+),?\s*comment\s*(\s|%\#)(\d+)     
will link to to a specific comment in a specific bug.

This is the basic standard for citing bug reports (Also FYI: There is no
official standard way for citing them in "real" documents, other than
using the proper citation form for their URL's or something.)

I'm not going to modify the bugzilla source (to recognize any other
citation forms, as this highlighting is done in a routine used all over
the place (and thus, it's harder to verify a given regex does what you
expect in all cases), and I am specifically trying to avoid making any
changes to the perl source that can be avoided (the templates are
expected to be changed).

> 
> Michael C

Re: [patch] gdb.c++/local.exp: add pr numbers

[Michael Elizabeth Chastain]

Kevin Buettner asks:
> What happens as the bugs are fixed?  Do we then take the PR numbers
> out?

That brings up a good issue.

The test code that I have right now is resilient to this.  Viz:

  send_gdb "foo ..."
  gdb_expect {
    -re "bar\r\n$gdb_prompt $" {
      pass "foo"
    }
    -re "bletch\r\n$gdb_prompt $" {
      # setup_kfail "gnats:gdb/NNN"
      fail "foo (gnats:gdb/NNN)"
    }
    -re ".*$gdb_prompt $" {
      fail "foo"
    }
    timeout {
      fail "foo (timeout)"
    }

"bar" is a good response.  "bletch" is a particular known bad response.
So as long as gdb responds with "bletch", it will be a FAIL
(soon to be a KFAIL).

When gdb starts responding with "bar", a good response, the test will PASS.

There is no need to remove the case for "bletch" for a long time.
Eventually someone will do a cleanup pass and notice that the bug for
"bletch" got fixed 2 years ago.  It's never dangerous to remove the
"bletch" case because that will just give the ordinary ".*" FAIL again.

I was thinking about this today.  The real issue is where to represent
information about known failures.  The bug database holds one view of
this information, and now we are putting it into the test scripts as well,
via KFAIL.  That means significantly more activity in the test scripts.

Michael C

[patch] gdb.c++/local.exp: add pr numbers

[Michael Elizabeth Chastain]

This patch adds gnats PR numbers to gdb.c++/local.exp for the tests which
are known to fail.  Twenty-four hours for comments, and then I'll apply.

Michael C

2002-04-12  Michael Chastain  <mec@shout.net>

	* gdb.c++/local.exp: Add PR numbers: pr gdb/482, pr gdb/483.

Index: gdb.c++/local.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.c++/local.exp,v
retrieving revision 1.7
diff -c -3 -p -r1.7 local.exp
*** gdb.c++/local.exp	10 Apr 2002 03:52:21 -0000	1.7
--- gdb.c++/local.exp	12 Apr 2002 22:25:33 -0000
*************** set sep "(\[.\]|___)\[0-9\]"
*** 101,107 ****
  send_gdb "ptype Local\n"
  gdb_expect {
    -re "type = class Local \{\[\r\n\t \]*public:\[\r\n\t \]*int loc1;\[\r\n\t \]*char loc_foo\\((const *|)char\\);\[\r\n\t \]*\}.*$gdb_prompt $" { pass "ptype Local" }
!   -re "type = class Local \{\[\r\n\t \]*public:\[\r\n\t \]*int loc1;\[\r\n\t \]*char loc_foo\\((const *|)char\\);\[\r\n\t \]*char loc_foo\\((const *|)char\\);\[\r\n\t \]*\}.*$gdb_prompt $" { fail "ptype Local (double loc_foo)" }
    -re "type = class Local \{\[\r\n\t \]*public:\[\r\n\t \]*int loc1;\[\r\n\t \]*Local & operator *=\\((foobar__Fi${sep}::|)Local const *&\\);\[\r\n\t \]*Local\\((foobar__Fi${sep}::|)Local const *&\\);\[\r\n\t \]*Local\\((void|)\\);\[\r\n\t \]*char loc_foo\\(char\\);\[\r\n\t \]*\}.*$gdb_prompt $" { pass "ptype Local" }
    -re "type = class Local \{\r\n\[\t \]*public:\r\n\[\t \]*int loc1;\r\n\r\n\[\t \]*char loc_foo\\(char\\);\r\n\[\t \]*\\(Local at.*local\\.cc:\[0-9\]*\\)\r\n\}.*$gdb_prompt $" { xpass "ptype Local (old aCC)" }
    -re ".*$gdb_prompt $"   {  fail "ptype Local" }
--- 101,110 ----
  send_gdb "ptype Local\n"
  gdb_expect {
    -re "type = class Local \{\[\r\n\t \]*public:\[\r\n\t \]*int loc1;\[\r\n\t \]*char loc_foo\\((const *|)char\\);\[\r\n\t \]*\}.*$gdb_prompt $" { pass "ptype Local" }
!   -re "type = class Local \{\[\r\n\t \]*public:\[\r\n\t \]*int loc1;\[\r\n\t \]*char loc_foo\\((const *|)char\\);\[\r\n\t \]*char loc_foo\\((const *|)char\\);\[\r\n\t \]*\}.*$gdb_prompt $" {
!     # setup_kfail "gnats:gdb/483"
!     fail "ptype Local (gnats:gdb/483)"
!   }
    -re "type = class Local \{\[\r\n\t \]*public:\[\r\n\t \]*int loc1;\[\r\n\t \]*Local & operator *=\\((foobar__Fi${sep}::|)Local const *&\\);\[\r\n\t \]*Local\\((foobar__Fi${sep}::|)Local const *&\\);\[\r\n\t \]*Local\\((void|)\\);\[\r\n\t \]*char loc_foo\\(char\\);\[\r\n\t \]*\}.*$gdb_prompt $" { pass "ptype Local" }
    -re "type = class Local \{\r\n\[\t \]*public:\r\n\[\t \]*int loc1;\r\n\r\n\[\t \]*char loc_foo\\(char\\);\r\n\[\t \]*\\(Local at.*local\\.cc:\[0-9\]*\\)\r\n\}.*$gdb_prompt $" { xpass "ptype Local (old aCC)" }
    -re ".*$gdb_prompt $"   {  fail "ptype Local" }
*************** send_gdb "ptype InnerLocal::NestedInnerL
*** 186,192 ****
  gdb_expect {
    -re "type = class InnerLocal::NestedInnerLocal \{\[\r\n\t \]*public:\[\r\n\t \]*int nil;\[\r\n\t \]*int nil_foo\\(int\\);\[\r\n\t \]*\}.*$gdb_prompt $" { pass "ptype InnerLocal::NestedInnerLocal" }
    -re "type = class InnerLocal::NestedInnerLocal \{\[\r\n\t \]*public:\[\r\n\t \]*int nil;\[\r\n\t \]*NestedInnerLocal *& *operator *= *\\((main${sep}::|)InnerLocal::NestedInnerLocal const *&\\);\[\r\n\t \]*NestedInnerLocal\\((main${sep}::|)InnerLocal::NestedInnerLocal const *&\\);\[\r\n\t \]*NestedInnerLocal\\((void|)\\);\[\r\n\t \]*int nil_foo\\(int\\);\[\r\n\t \]*\}.*$gdb_prompt $" { pass "ptype InnerLocal::NestedInnerLocal" }
!   -re "There is no field named NestedInnerLocal.*$gdb_prompt $" { fail "ptype InnerLocal::NestedInnerLocal (bogus field lookup)" }
    -re "No symbol .*NestedInnerLocal.* in current context.*$gdb_prompt $" { fail "ptype InnerLocal::NestedInnerLocal (bogus symbol lookup)" }
    -re ".*$gdb_prompt $"   {  fail "ptype InnerLocal::NestedInnerLocal" }
    timeout             { fail "(timeout) ptype InnerLocal::NestedInnerLocal" }
--- 189,198 ----
  gdb_expect {
    -re "type = class InnerLocal::NestedInnerLocal \{\[\r\n\t \]*public:\[\r\n\t \]*int nil;\[\r\n\t \]*int nil_foo\\(int\\);\[\r\n\t \]*\}.*$gdb_prompt $" { pass "ptype InnerLocal::NestedInnerLocal" }
    -re "type = class InnerLocal::NestedInnerLocal \{\[\r\n\t \]*public:\[\r\n\t \]*int nil;\[\r\n\t \]*NestedInnerLocal *& *operator *= *\\((main${sep}::|)InnerLocal::NestedInnerLocal const *&\\);\[\r\n\t \]*NestedInnerLocal\\((main${sep}::|)InnerLocal::NestedInnerLocal const *&\\);\[\r\n\t \]*NestedInnerLocal\\((void|)\\);\[\r\n\t \]*int nil_foo\\(int\\);\[\r\n\t \]*\}.*$gdb_prompt $" { pass "ptype InnerLocal::NestedInnerLocal" }
!   -re "There is no field named NestedInnerLocal.*$gdb_prompt $" {
!     # setup_kfail "gnats:gdb/482"
!     fail "ptype InnerLocal::NestedInnerLocal (gnats:gdb/482)"
!   }
    -re "No symbol .*NestedInnerLocal.* in current context.*$gdb_prompt $" { fail "ptype InnerLocal::NestedInnerLocal (bogus symbol lookup)" }
    -re ".*$gdb_prompt $"   {  fail "ptype InnerLocal::NestedInnerLocal" }
    timeout             { fail "(timeout) ptype InnerLocal::NestedInnerLocal" }

Re: [patch] gdb.c++/local.exp: add pr numbers

[Kevin Buettner]

On Apr 12,  5:27pm, Michael Elizabeth Chastain wrote:

> This patch adds gnats PR numbers to gdb.c++/local.exp for the tests which
> are known to fail.  Twenty-four hours for comments, and then I'll apply.

What happens as the bugs are fixed?  Do we then take the PR numbers
out?

Kevin

Re: [patch] gdb.c++/local.exp: add pr numbers

[Daniel Jacobowitz]

On Fri, Apr 12, 2002 at 05:08:33PM -0700, Kevin Buettner wrote:
> On Apr 12,  5:27pm, Michael Elizabeth Chastain wrote:
> 
> > This patch adds gnats PR numbers to gdb.c++/local.exp for the tests which
> > are known to fail.  Twenty-four hours for comments, and then I'll apply.
> 
> What happens as the bugs are fixed?  Do we then take the PR numbers
> out?

IMO, no - we leave them and the entries stay in the PR database's
history.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [patch] gdb.c++/local.exp: add pr numbers

[Andrew Cagney]

> !     fail "ptype InnerLocal::NestedInnerLocal (gnats:gdb/482)"

Suggest just ``(gdb/482)''.  It appears GCC really is switching to 
Bugzilla so ``gnats'' may one day not apply.

Andrew