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

[Andrea Corallo]

Andrea Corallo <akrl@sdf.org> writes:

> 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.

Hi Eli,

is there anything left to be done for this bug?

TIA

  Andrea