bug#47024: 28.0.50; [feature/native-comp] Warnings from async compilations truncated

[Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Andrea Corallo <akrl@sdf.org>
>>> Cc: 47024@debbugs.gnu.org
>>> Date: Wed, 10 Mar 2021 13:12:59 +0000
>>>
>>> >  seq.el:396:16: Warning: `seq-contains' is an obsolete generic function (as of
>>> >      27.1); use `seq-contains-p' instead.
>>> >
>>> > There's an actual newline at the end of the first line, because by
>>> > default we _fill_ the text.
>>> >
>>> > So I think the solution should be to bind (in the sub-process which
>>> > performs the actual compilation) warning-fill-column to a large
>>> > number.
>>>
>>> Nice, is 256 a reasonable number?
>>
>> How about most-positive-fixnum?
>
> Sounds good, fe1c081c38 does that.
>
>>> > Is there a similar issue with error messages?
>>>
>>> Yes, we suffer from the same issue if the Error is emitted with new
>>> lines.
>>
>> But is there a similar variable to bind in that case? fill-column,
>> perhaps?
>
> Dunno, I'll make some tests if we don't get a precise suggestion.

With 0144764d1d error reporting appears to be working for me.

I had no problems with line truncations but I had to tweak the way we
are printing them (before we emitted always the full backtrace) so now
we can parse them and report to the user correctly.

My testcase is to signal and error with a very long message within an
`eval-when-compile' and I see it now reported entirely in the
"*Async-native-compile-log*".

Please let me know if you have some other suggestion on how to test
this.

Thanks

  Andrea