From mahmood at MIT.EDU Mon Dec 15 17:00:27 2008 From: mahmood at MIT.EDU (Mahmood Ali) Date: Mon, 15 Dec 2008 20:00:27 -0500 Subject: RFE: compile/fail tag to recognize compiler failures Message-ID: Greetings, I would like to request changing compile/fail tag semantics a bit. Currently if the compile fails to compile the provided class, the test passes regardless of the reason of the failure. jtreg does not distinguish between failures due to compiler reported errors or unexpected exceptions in the compiler. I request that jtreg to recognize these unexpected errors and treat them differently from expected errors and not ignore them silently. Regards, Mahmood From mahmood at MIT.EDU Mon Dec 15 17:00:27 2008 From: mahmood at MIT.EDU (Mahmood Ali) Date: Mon, 15 Dec 2008 20:00:27 -0500 Subject: RFE: compile/fail tag to recognize compiler failures Message-ID: Greetings, I would like to request changing compile/fail tag semantics a bit. Currently if the compile fails to compile the provided class, the test passes regardless of the reason of the failure. jtreg does not distinguish between failures due to compiler reported errors or unexpected exceptions in the compiler. I request that jtreg to recognize these unexpected errors and treat them differently from expected errors and not ignore them silently. Regards, Mahmood From Jonathan.Gibbons at Sun.COM Mon Dec 15 17:22:39 2008 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Mon, 15 Dec 2008 17:22:39 -0800 Subject: RFE: compile/fail tag to recognize compiler failures In-Reply-To: References: Message-ID: <494702DF.50908@sun.com> Mahmood, This is not possible because of a combination of reasons, but there are workarounds. The problem is that jtreg can potentially invoke the compiler in another JVM, and so it would require cooperation from the compiler to get the information you require. But jtreg is also spec-ed to work with older versions of the compiler, where we cannot retrofit any such behavior. There are two workarounds. One is to write the test using "@run main" instead of "@compile/fail" and to use JSR 199 to drive the compiler. You can get significantly better control of the compiler using JSR 199. You can have the code to invoke the compiler in a library class, and have the library class put on the the classpath with the @library tag. You can run this sort of test with something like this @library ../lib @build MyCompilerWrapper @run main MyCompilerWrapper args The second workaround is to use golden file testing. To avoid dependence on the localization of error messages, you can use a hidden compiler option -XDrawDiagnostics, which prints the error message in a "raw" non-localized form. You can run this sort of test with @compile/fail/ref=MyGolden.out -XDrawDiagnostics MyTest.java You should be able to find examples of both types of test in the langtools repository. For use of @library, see, for example, javadoc tests and JavadocTester (sp?) For use of -XDrawDiagnostics, grep the javac tests. -- Jon Mahmood Ali wrote: > Greetings, > > I would like to request changing compile/fail tag semantics a bit. > > Currently if the compile fails to compile the provided class, the test > passes regardless of the reason of the failure. jtreg does not > distinguish between failures due to compiler reported errors or > unexpected exceptions in the compiler. > > I request that jtreg to recognize these unexpected errors and treat > them differently from expected errors and not ignore them silently. > > Regards, > Mahmood >