From: Andrew Cagney <ac131313@redhat.com>
To: gdb-patches@sources.redhat.com
Subject: [rfa/testsuite] More complaints tests
Date: Mon, 23 Sep 2002 15:29:00 -0000 [thread overview]
Message-ID: <3D8F95D7.9020906@redhat.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 321 bytes --]
Hello,
The attached explicitly tests the underlying problem that was causing
weird.exp to fail.
Briefly, when there wern't any complaint calls, the [broken] code could
generate an unnecessary new line.
Ok?
Andrew
(I've also attached the complaints fix I really committed. The testing
flushed out more problems.)
[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 2016 bytes --]
2002-09-23 Andrew Cagney <ac131313@redhat.com>
* gdb.gdb/complaints.exp (test_initial_complaints): Rename
test_isolated_complaints.
(test_empty_complaint): New function.
(test_empty_complaints): New function. Check no output when no
complaints.
Index: gdb.gdb/complaints.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.gdb/complaints.exp,v
retrieving revision 1.1
diff -u -r1.1 complaints.exp
--- gdb.gdb/complaints.exp 19 Sep 2002 15:22:47 -0000 1.1
+++ gdb.gdb/complaints.exp 23 Sep 2002 22:19:31 -0000
@@ -101,7 +101,7 @@
return 0
}
-proc test_isolated_complaints { } {
+proc test_initial_complaints { } {
global gdb_prompt
@@ -233,6 +233,41 @@
return 0
}
+# Check that nothing comes out when there haven't been any real
+# complaints. Note that each test is really checking the previous
+# command.
+
+proc test_empty_complaint { cmd msg } {
+ global gdb_prompt
+ send_gdb $cmd
+ gdb_expect {
+ -re "\r\n\r\n$gdb_prompt " {
+ fail $msg
+ }
+ "\r\n$gdb_prompt" {
+ pass $msg
+ }
+ timeout {
+ fail "$msg (timeout)"
+ }
+ }
+
+}
+
+proc test_empty_complaints { } {
+
+ test_empty_complaint "call clear_complaints(&symfile_complaints,0,0)\n" \
+ "empty non-verbose non-noisy clear"
+ test_empty_complaint "call clear_complaints(&symfile_complaints,1,0)\n" \
+ "empty verbose non-noisy clear"
+ test_empty_complaint "call clear_complaints(&symfile_complaints,1,1)\n" \
+ "empty verbose noisy clear"
+ test_empty_complaint "call clear_complaints(&symfile_complaints,0,1)\n" \
+ "empty non-verbose noisy clear"
+
+ return 0
+}
+
# Find a pathname to a file that we would execute if the shell was asked
# to run $arg using the current PATH.
@@ -274,9 +309,10 @@
return -1
}
-test_isolated_complaints
+test_initial_complaints
test_serial_complaints
test_short_complaints
+test_empty_complaints
gdb_exit;
catch "remote_file host delete $file";
[-- Attachment #3: committed --]
[-- Type: text/plain, Size: 2571 bytes --]
2002-09-21 Andrew Cagney <cagney@redhat.com>
* complaints.c (symfile_explanations): Remove new-line from
``isolated_message''.
(vcomplaint): When ISOLATED_MESSAGE, force a line break.
(clear_complaints): When a SUBSEQUENT_MESSAGE, force a line break.
Index: complaints.c
===================================================================
RCS file: /cvs/src/src/gdb/complaints.c,v
retrieving revision 1.7
diff -u -r1.7 complaints.c
--- complaints.c 19 Sep 2002 00:42:41 -0000 1.7
+++ complaints.c 21 Sep 2002 15:30:37 -0000
@@ -84,7 +84,7 @@
/* The symbol table complaint table. */
static const char *symfile_explanations[] = {
- "During symbol reading, %s.\n",
+ "During symbol reading, %s.",
"During symbol reading...%s...",
"%s...",
"%s...",
@@ -181,6 +181,7 @@
else
{
if (complaints->explanation == NULL)
+ /* A [v]warning() call always appends a newline. */
vwarning (complaint->fmt, args);
else
{
@@ -194,7 +195,17 @@
fprintf_filtered (gdb_stderr,
complaints->explanation[series],
msg);
- wrap_here ("");
+ /* Force a line-break after any isolated message. For the
+ other cases, clear_complaints() takes care of any missing
+ trailing newline, the wrap_here() is just a hint. */
+ if (series == ISOLATED_MESSAGE)
+ /* It would be really nice to use begin_line() here.
+ Unfortunatly that function doesn't track GDB_STDERR and
+ consequently will sometimes supress a line when it
+ shouldn't. */
+ fputs_filtered ("\n", gdb_stderr);
+ else
+ wrap_here ("");
do_cleanups (cleanups);
}
}
@@ -267,10 +278,26 @@
p->counter = 0;
}
- if (complaints->series > 1 && !warning_hook)
+ switch (complaints->series)
{
- /* Terminate previous series, since caller won't. */
- puts_filtered ("\n");
+ case FIRST_MESSAGE:
+ /* Haven't yet printed anything. */
+ break;
+ case SHORT_FIRST_MESSAGE:
+ /* Haven't yet printed anything. */
+ break;
+ case ISOLATED_MESSAGE:
+ /* The code above, always forces a line-break. No need to do it
+ here. */
+ break;
+ case SUBSEQUENT_MESSAGE:
+ /* It would be really nice to use begin_line() here.
+ Unfortunatly that function doesn't track GDB_STDERR and
+ consequently will sometimes supress a line when it shouldn't. */
+ fputs_unfiltered ("\n", gdb_stderr);
+ break;
+ default:
+ internal_error (__FILE__, __LINE__, "bad switch");
}
if (!less_verbose)
next reply other threads:[~2002-09-23 22:29 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-23 15:29 Andrew Cagney [this message]
2002-09-24 7:44 ` Fernando Nasser
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=3D8F95D7.9020906@redhat.com \
--to=ac131313@redhat.com \
--cc=gdb-patches@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