[m-rev.] for post-commit review: make --output-compiler-error-lines a maybe_int option

Zoltan Somogyi zoltan.somogyi at runbox.com
Mon Aug 7 10:50:32 AEST 2023


On 2023-08-07 02:40 +02:00 CEST, "Peter Wang" <novalazy at gmail.com> wrote:
>>  @item --output-compile-error-lines @var{n}
>> + at item --no-output-compile-error-lines
>>  @findex --output-compile-error-lines
>>  @findex --make
>>  With @samp{--make}, output the first @var{n} lines of the @samp{.err}
>>  file after compiling a module (default: 15).
>> +Specifying --no-output-compile-error-lines removes the limit.
> 
> --no-output-compile-error-lines sounds like the opposite of what it
> does, but that's okay.

There was already a problem with the name, in that the compiler
output *usually* consists of error messages, but it can also include
progress messages (with -v or -V) and inference messages.
It also does not imply that it is a limit.

Would something --max-compiler-output-lines or --max-echoed-output-lines
work better? They handle a --no in front much better.

Another thought: should we specify --no-<whatever option name we end up with>
in the test directories? It would make the bootcheck output in csharp and java
grades more immediately useful, in that you could look up the diagnostics
associated with a test failure in the bootcheck output file itself, without necessarily
looking at the .err file.

Zoltan.

Zoltan.


More information about the reviews mailing list