Re: RFR: JDK-8201320 Feature request: Allow PrintFailureReports to be turned off

2018-04-10 Thread Erik Joelsson
Ah it was run without spec before. Looks good then. /Erik On 2018-04-10 14:31, Magnus Ihse Bursie wrote: On 2018-04-10 23:24, Erik Joelsson wrote: Hello, Nice feature! Init.gmk: 229 were -> was Fixed without new webrev. Otherwise looks good. Out of curiosity, was there a reason to

Re: RFR: JDK-8201320 Feature request: Allow PrintFailureReports to be turned off

2018-04-10 Thread Magnus Ihse Bursie
On 2018-04-10 23:24, Erik Joelsson wrote: Hello, Nice feature! Init.gmk: 229 were -> was Fixed without new webrev. Otherwise looks good. Out of curiosity, was there a reason to move the log parsing macros outside of has-spec block? It doesn't look like you changed where you call these

Re: RFR: JDK-8201320 Feature request: Allow PrintFailureReports to be turned off

2018-04-10 Thread Erik Joelsson
Hello, Nice feature! Init.gmk: 229 were -> was Otherwise looks good. Out of curiosity, was there a reason to move the log parsing macros outside of has-spec block? It doesn't look like you changed where you call these macros from. /Erik On 2018-04-10 13:54, Magnus Ihse Bursie wrote:

Re: RFR: JDK-8201320 Feature request: Allow PrintFailureReports to be turned off

2018-04-10 Thread Stefan Karlsson
Hi Magnus, Thanks a lot for implementing this! I tested this with --with-log=info,report=none, and it's exactly what I want in my config script ;) Thanks, StefanK On 2018-04-10 22:54, Magnus Ihse Bursie wrote: From the bug report: "The compile errors you get from HotSpot are quite large,

RFR: JDK-8201320 Feature request: Allow PrintFailureReports to be turned off

2018-04-10 Thread Magnus Ihse Bursie
From the bug report: "The compile errors you get from HotSpot are quite large, and usually don't get entirely printed in PrintFailureReports. This has the effect that the goto mode to find the compilation error is to scroll past PrintFailureReports to get to the complete error message. It