bug#43725: 28.0.50; Include feature/native-comp into master

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: larsi@gnus.org, monnier@iro.umontreal.ca, 43725@debbugs.gnu.org
>> Date: Mon, 15 Mar 2021 15:43:07 +0000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > The issue is this: our Lisp files are generally encoded in UTF-8.  But
>> > there's no guarantee that GCC expects the source to be encoded in
>> > UTF-8.  If the text we submit to libgccjit for compilation is in the
>> > same encoding as the original .el files, then shouldn't we tell GCC
>> > its actual encoding, to make sure non-ASCII text aren't mangled?
>> 
>> The only generated text we are passing to libgccjit is feed to
>> 'gcc_jit_context_new_string_literal'.
>
> What kind of "string literals" go this way?  Are these constant
> strings from Lisp, or can some other data types from Lisp end up being
> passed like that?

This are essentially all Lisp objects that we'd put in the constant
vector for the bytecode case.

>> This text is generated from 'Fprin1_to_string' that we use to
>> essentially render in form of text immediate objects.  I thought
>> this was disconnected from the encoding of the source file, am I
>> wrong?
>
> If the original text is from Lisp strings in the Lisp source file,
> then it isn't disconnected.  Those strings could include non-ASCII
> characters, and they come out in UTF-8 (well, almost, modulo the raw
> bytes etc.).

In december I've fixed a bug for multibyte strings adding also a
testcase for that.  This was bug#45342 and the commit fixing and adding
the testcase is 72c1a41573.

I'm no big expert into this area so you might want to have a look to the
commit to suggets if this covers already the case you are suggesting or
not.

Thanks!

  Andrea