* sourcebuild.texi (Test Idioms): Update testcase naming

	conventions.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@77306 138bc75d-0d04-0410-961f-82ee72b054a4

2 files changed, 20 insertions, 7 deletions

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 79977d1ea21..f769f9f4066 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2004-02-05  Joseph S. Myers  <jsm@polyomino.org.uk>
+
+	* sourcebuild.texi (Test Idioms): Update testcase naming
+	conventions.
+
 2004-02-04  Per Bothner  <per@bothner.com>
 
 	Partially revert/redo 2003-10-01 change; fix -fworking-directory.
diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index d21e863a94e..8d08827f046 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -788,13 +788,21 @@ here; FIXME: document the others.
 @node Test Idioms
 @subsection Idioms Used in Test Suite Code
 
-In the @file{gcc.c-torture} test suites, test cases are commonly named
-after the date on which they were added.  This allows people to tell
-at a glance whether a test failure is because of a recently found bug
-that has not yet been fixed, or whether it may be a regression.  In
-other test suites, more descriptive names are used.  In general C test
-cases have a trailing @file{-@var{n}.c}, starting with @file{-1.c}, in
-case other test cases with similar names are added later.
+In general C testcases have a trailing @file{-@var{n}.c}, starting
+with @file{-1.c}, in case other testcases with similar names are added
+later.  If the test is a test of some well-defined feature, it should
+have a name referring to that feature such as
+@file{@var{feature}-1.c}.  If it does not test a well-defined feature
+but just happens to exercise a bug somewhere in the compiler, and a
+bug report has been filed for this bug in the GCC bug database,
+@file{pr@var{bug-number}-1.c} is the appropriate form of name.
+Otherwise (for miscellaneous bugs not filed in the GCC bug database),
+and previously more generally, test cases are named after the date on
+which they were added.  This allows people to tell at a glance whether
+a test failure is because of a recently found bug that has not yet
+been fixed, or whether it may be a regression, but does not give any
+other information about the bug or where discussion of it may be
+found.  Some other language testsuites follow similar conventions.
 
 Test cases should use @code{abort ()} to indicate failure and
 @code{exit (0)} for success; on some targets these may be redefined to