[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#43725: 28.0.50; Include feature/native-comp into master
From: |
Andrea Corallo |
Subject: |
bug#43725: 28.0.50; Include feature/native-comp into master |
Date: |
Mon, 15 Mar 2021 20:00:17 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
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
- bug#43725: 28.0.50; Include feature/native-comp into master, (continued)
- bug#43725: 28.0.50; Include feature/native-comp into master, Eli Zaretskii, 2021/03/10
- bug#43725: 28.0.50; Include feature/native-comp into master, Andrea Corallo, 2021/03/10
- bug#43725: 28.0.50; Include feature/native-comp into master, Andrea Corallo, 2021/03/10
- bug#43725: 28.0.50; Include feature/native-comp into master, Eli Zaretskii, 2021/03/14
- bug#43725: 28.0.50; Include feature/native-comp into master, Andrea Corallo, 2021/03/14
- bug#43725: 28.0.50; Include feature/native-comp into master, Eli Zaretskii, 2021/03/14
- bug#43725: 28.0.50; Include feature/native-comp into master, Andrea Corallo, 2021/03/14
- bug#43725: 28.0.50; Include feature/native-comp into master, Eli Zaretskii, 2021/03/15
- bug#43725: 28.0.50; Include feature/native-comp into master, Andrea Corallo, 2021/03/15
- bug#43725: 28.0.50; Include feature/native-comp into master, Eli Zaretskii, 2021/03/15
- bug#43725: 28.0.50; Include feature/native-comp into master,
Andrea Corallo <=
- bug#43725: 28.0.50; Include feature/native-comp into master, Eli Zaretskii, 2021/03/20
- bug#43725: 28.0.50; Include feature/native-comp into master, Eli Zaretskii, 2021/03/20
- bug#43725: 28.0.50; Include feature/native-comp into master, Andrea Corallo, 2021/03/21
- bug#43725: 28.0.50; Include feature/native-comp into master, Eli Zaretskii, 2021/03/21
- bug#43725: 28.0.50; Include feature/native-comp into master, Eli Zaretskii, 2021/03/15