trlc crash when used in pipeline

[florianschanda]

In some scenarios, calling TRLC and piping the output to head creates a crash:

$ trlc | head
T foo1 {x = 1}
  ^^^^ ./foo.trlc:2: check warning: potato
T foo10 {x = 1}
  ^^^^^ ./foo.trlc:11: check warning: potato
T foo100 {x = 1}
  ^^^^^^ ./foo.trlc:101: check warning: potato
T foo101 {x = 1}
  ^^^^^^ ./foo.trlc:102: check warning: potato
T foo102 {x = 1}
  ^^^^^^ ./foo.trlc:103: check warning: potato
Traceback (most recent call last):
  <snip>
  File "/home/potato/.local/lib/python3.10/site-packages/trlc/errors.py", line 220, in emit
    print(context[1].replace("\t", " "), msg)
BrokenPipeError: [Errno 32] Broken pipe

You can reproduce this by creating a lot of text, e.g:

package Foo

type T {
  x Integer
}

checks T {
  x == 0, warning "potato"
}

And then generate a body:

echo "package Foo" > foo.trlc
for I in $(seq 1 400); do echo "T foo$I {x = 1}" >> foo.trlc; done

I think the way to deal with this is to rename main (

trlc/trlc/trlc.py

Line 553 in 9d804f1

def main():

), and create a new main that just calls it, but also catches BrokenPipeError and quits silently.

[phiwuu]

@florianschanda, thanks for your bug report. In your opinion, should trlc terminate with return code 0 or 1 when piping it to e.g. head?
In my opinion, return code 0 only makes sense if trlc was able to digest all input files to the end (and without problems). If it is forced to terminate early, return code 0 does not make sense. Do you agree?

My point here is the following:

• If somebody uses trlc in their company's CI system
• and they rely on the return code (i.e. allow a merge of TRLC files if trlc returns 0,
• and they introduce some kind of pipes in their CI system (for logging or whatever purpose),
• and this pipe terminates too early (maybe it terminates only early by one character before trlc finishes)
• and the *.trlc files in their pull request do contain errors

then the CI would allow to merge the PR, if trlc returns 0. This is dangerous (bad requirements in main branch!) and very hard to debug. So I recommend not to fail silently, or at least it should exit with a non-zero return code.

We could use sys.exit(2) in case of a BrokenPipeError.

[christophkloeffel]

when using trlc . | head for example the exit code will always be the one of the rightmost command in the pipeline.
in this case 0.
that means if you rely on the exit code of the trlc tool, don't use it in a pipeline or you have to deal with some additional configuration like that https://stackoverflow.com/questions/1221833/pipe-output-and-capture-exit-status-in-bash.
so assuming someone wants to use trlc in a pipeline, relies on the exit code and has configured it correctly. Then you would get exit code 120 at the moment.

with the fix of #101 the exit code would be 141, but without printing an error.

Currently and with the fix of #101 there will be no exit code 0 unless they miss out to configure it correctly, in this case they do not get the exit code of trlc but of the rightmost command used in the pipeline. So I think your suggestion is already fulfilled, because we will always exit with 141 in case of a BrokenPipeError