GNU logs - #78394, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#78394: 31.0.50; Questions about native-comp-speed and type decl
Resent-From: "Yue Yi" <include_yy@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 12 May 2025 15:56:01 +0000
Resent-Message-ID: <handler.78394.B.174706533311194 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 78394 <at> debbugs.gnu.org
From: "Yue Yi" <include_yy@HIDDEN>
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="----=_NextPart_682219D5_13C997E8_0D93638F"
Content-Transfer-Encoding: 8Bit
Date: Mon, 12 May 2025 23:55:01 +0800
Message-ID: <tencent_F01FA7D8F74C389263C89576653B3438E707@HIDDEN>
Received-SPF: pass client-ip=203.205.221.242; envelope-from=include_yy@HIDDEN;
 helo=out203-205-221-242.mail.qq.com
X-Spam_score_int: 65
X-Spam_score: 6.5
X-Spam_bar: ++++++
X-Spam_report: (6.5 / 5.0 requ) BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2,
 DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.001, HELO_DYNAMIC_IPADDR=1.951,
 HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001,
 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001,
 RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=no autolearn_force=no
X-Spam_action: reject
X-Spam-Score: 0.9 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.1 (/)

This is a multi-part message in MIME format.

------=_NextPart_682219D5_13C997E8_0D93638F
Content-Type: text/plain;
	charset="gb18030"
Content-Transfer-Encoding: base64

SGVsbG8gRW1hY3MgbWFpbnRhaW5lcnMsIFdoZW4gbW9kaWZ5aW5nIGFuIG9yZyBIVE1MIGV4
cG9ydCBiYWNrZW5kLCBJIHRlbnRhdGl2ZWx5IGFkZGVkIHR5cGUgYW5ub3RhdGlvbnMgdG8g
YSBmdW5jdGlvbiB0byBtYWtlIHRoZSBjb2RlIHJ1biBmYXN0ZXIuIEhvd2V2ZXIsIGR1cmlu
ZyB1bml0IHRlc3RpbmcsIGJ5dGUgY29tcGlsYXRpb24gcHJvZHVjZWQgY29ycmVjdCByZXN1
bHRzLCB3aGlsZSBuYXRpdmUgY29tcGlsYXRpb24gZGlkIG5vdC4gU3BlY2lmaWNhbGx5LCB0
aGUgZm9sbG93aW5nIGNsZWFuZWQtdXAgY29kZSBpbGx1c3RyYXRlcyB0aGUgaXNzdWU6IC0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZndDs4PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tIChkZWZjb25zdCBteS9wbGlzdCAnKDpodG1sLWNoZWNrYm94LXR5cGUgdW5pY29k
ZSkpIChkZWZjb25zdCB0LWNoZWNrYm94LXR5cGVzICAgJygoIHVuaWNvZGUgLiAgICAgICAo
KG9uIC4gIoE3pDEiKSAob2ZmIC4gIoE3pDAiKSAgICAgICAgKHRyYW5zIC4gIoE3pDIiKSkp
KSkgKGxldCAoKG5hdGl2ZS1jb21wLXNwZWVkIDIpKSAgIChkZWZ1biB0LS1jaGVja2JveCAo
Y2hlY2tib3ggaW5mbykgICAgICJGb3JtYXQgQ0hFQ0tCT1ggaW50byBIVE1MLiIgICAgIChk
ZWNsYXJlIChmdHlwZSAoZnVuY3Rpb24gKHQgcGxpc3QpIHN0cmluZykpICAgICAoc2lkZS1l
ZmZlY3QtZnJlZSB0KSAoaW1wb3J0YW50LXJldHVybi12YWx1ZSB0KSkgICAgIChjZHIgKGFz
c3EgY2hlY2tib3ggICAgICAgICAgICAgICAgKGNkciAoYXNzcSAocGxpc3QtZ2V0IGluZm8g
Omh0bWwtY2hlY2tib3gtdHlwZSkgICAgICAgICAgICAgICAgICAgICAgICAgICB0LWNoZWNr
Ym94LXR5cGVzKSkpKSkgICAoZGVmdW4gdC0tZm9ybWF0LWNoZWNrYm94IChjaGVja2JveCBp
bmZvKSAgICAgIkZvcm1hdCBhIENIRUNLQk9YIG9wdGlvbiB0byBzdHJpbmcuIENIRUNLQk9Y
IGNhbiBiZSBgb24nLCBgb2ZmJywgYHRyYW5zJywgb3IgYW55dGhpbmcgZWxzZS4gUmV0dXJu
cyBhbiBlbXB0eSBzdHJpbmcgaWYgQ0hFQ0tCT1ggaXMgbm90IG9uZSBvZiB0aGUgdGhlc2Ug
dGhyZWUuIiAgICAgKGRlY2xhcmUgKGZ0eXBlIChmdW5jdGlvbiAodCBwbGlzdCkgc3RyaW5n
KSkgICAgIChzaWRlLWVmZmVjdC1mcmVlIHQpIChpbXBvcnRhbnQtcmV0dXJuLXZhbHVlIHQp
KSAgICAgKGxldCAoKGEgKHQtLWNoZWNrYm94IGNoZWNrYm94IGluZm8pKSkgICAgICAgKGNv
bmNhdCBhIChhbmQgYSAiICIpKSkpICAgOzsgbmF0aXZlIGNvbXAgICAobmF0aXZlLWNvbXBp
bGUgJ3QtLWNoZWNrYm94KSAgIChuYXRpdmUtY29tcGlsZSAndC0tZm9ybWF0LWNoZWNrYm94
KSkgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0Ozg8LS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0gQUZBQ0ssIHRoZSBkZWZhdWx0IHZhbHVlIG9mIGBuYXRpdmUtY29tcC1z
cGVlZCcgaXMgMi4gSW4gdGhpcyBjYXNlLCB0aGUgYmVoYXZpb3Igb2YgdGhlIGZvbGxvd2lu
ZyBjb2RlIGlzIGluY29uc2lzdGVudCB3aXRoIHRoYXQgb2YgdGhlIGJ5dGUtY29tcGlsZWQg
b3Igbm9uLWNvbXBpbGVkIGNvZGU6IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZndDs4
PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIDs7IG5vcm1hbCAodC0tZm9ybWF0LWNo
ZWNrYm94IG5pbCBteS9wbGlzdCkgOzs9Jmd0OyAiIiA7OyBieXRlLWNvZGUgKHQtLWZvcm1h
dC1jaGVja2JveCBuaWwgbXkvcGxpc3QpIDs7PSZndDsgIiIgOzsgc3BlZWQgMSAodC0tZm9y
bWF0LWNoZWNrYm94IG5pbCBteS9wbGlzdCkgOzs9Jmd0OyAiIiA7OyBzcGVlZCAyICh0LS1m
b3JtYXQtY2hlY2tib3ggbmlsIG15L3BsaXN0KSA7Oz0mZ3Q7ICIgIiAtLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0mZ3Q7ODwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBPZiBj
b3Vyc2UsIHdlIGNhbiBub3RpY2UgdGhhdCB0aGUgdHlwZSBkZWNsYXJhdGlvbiBmb3IgYHQt
LWNoZWNrYm94JyBpcyBwcm9ibGVtYXRpYyAtLS0gaXRzIHJldHVybiB0eXBlIHNob3VsZCBi
ZSAob3IgbnVsbCBzdHJpbmcpIGluc3RlYWQgb2Ygc3RyaW5nLiBBZnRlciBjb3JyZWN0aW5n
IHRoaXMgbWlzdGFrZSwgdGhlIGZ1bmN0aW9uIHdvcmtzIHByb3Blcmx5IHVuZGVyIHNwZWVk
PTIuIEluIEMsIHdlIGdlbmVyYWxseSBhdm9pZCBhZ2dyZXNzaXZlIG9wdGltaXphdGlvbnMg
YmVjYXVzZSB0aGV5IGNhbiBsZWFkIHRvIHVucHJlZGljdGFibGUgYmVoYXZpb3IuIFdoYXQg
SaGvZCBsaWtlIHRvIGFzayBpcyB3aGV0aGVyIHNpbWlsYXIgc2l0dWF0aW9ucyBjYW4gb2Nj
dXIgaW4gRW1hY3MgTGlzcKGvcyBuYXRpdmUgY29tcGlsYXRpb24gYXMgd2VsbCAtLS0gbGlr
ZSB0aGUgaXNzdWUgSSBlbmNvdW50ZXJlZCBoZXJlPyBBbm90aGVyIHF1ZXN0aW9uIGlzIGFi
b3V0IGBjb21waWxhdGlvbi1zYWZldHknLiBBcyBJIHVuZGVyc3RhbmQgaXQsIHdoZW4gc2V0
IHRvIDEsIGl0IHByZXZlbnRzIEVtYWNzIGZyb20gY3Jhc2hpbmcgZHVlIHRvIGZhdWx0eSBv
cHRpbWl6YXRpb25zLiBEb2VzIHRoaXMgbWVhbiB0aGUgdmFyaWFibGUgb25seSBndWFyZHMg
YWdhaW5zdCB0aGUgbW9zdCBzZXZlcmUgY2FzZXMsIHJhdGhlciB0aGFuIGVuc3VyaW5nIHRo
ZSBjb3JyZWN0bmVzcyBvZiBvcHRpbWl6YXRpb25zIGluIGdlbmVyYWw/IEJlc3QgcmVnYXJk
cy4=

------=_NextPart_682219D5_13C997E8_0D93638F
Content-Type: text/html;
	charset="gb18030"
Content-Transfer-Encoding: base64

PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNo
YXJzZXQ9R0IxODAzMCI+PHByZT5IZWxsbyBFbWFjcyBtYWludGFpbmVycywKCldoZW4gbW9k
aWZ5aW5nIGFuIG9yZyBIVE1MIGV4cG9ydCBiYWNrZW5kLCBJIHRlbnRhdGl2ZWx5IGFkZGVk
IHR5cGUKYW5ub3RhdGlvbnMgdG8gYSBmdW5jdGlvbiB0byBtYWtlIHRoZSBjb2RlIHJ1biBm
YXN0ZXIuIEhvd2V2ZXIsIGR1cmluZwp1bml0IHRlc3RpbmcsIGJ5dGUgY29tcGlsYXRpb24g
cHJvZHVjZWQgY29ycmVjdCByZXN1bHRzLCB3aGlsZSBuYXRpdmUKY29tcGlsYXRpb24gZGlk
IG5vdC4gU3BlY2lmaWNhbGx5LCB0aGUgZm9sbG93aW5nIGNsZWFuZWQtdXAgY29kZQppbGx1
c3RyYXRlcyB0aGUgaXNzdWU6CgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7OCZs
dDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQooZGVmY29uc3QgbXkvcGxpc3QgJyg6
aHRtbC1jaGVja2JveC10eXBlIHVuaWNvZGUpKQooZGVmY29uc3QgdC1jaGVja2JveC10eXBl
cwogICcoKCB1bmljb2RlIC4KICAgICAgKChvbiAuICKBN6QxIikgKG9mZiAuICKBN6QwIikK
ICAgICAgICh0cmFucyAuICKBN6QyIikpKSkpCgoobGV0ICgobmF0aXZlLWNvbXAtc3BlZWQg
MikpCiAgKGRlZnVuIHQtLWNoZWNrYm94IChjaGVja2JveCBpbmZvKQogICAgIkZvcm1hdCBD
SEVDS0JPWCBpbnRvIEhUTUwuIgogICAgKGRlY2xhcmUgKGZ0eXBlIChmdW5jdGlvbiAodCBw
bGlzdCkgc3RyaW5nKSkKICAgIChzaWRlLWVmZmVjdC1mcmVlIHQpIChpbXBvcnRhbnQtcmV0
dXJuLXZhbHVlIHQpKQogICAgKGNkciAoYXNzcSBjaGVja2JveAogICAgICAgICAgICAgICAo
Y2RyIChhc3NxIChwbGlzdC1nZXQgaW5mbyA6aHRtbC1jaGVja2JveC10eXBlKQogICAgICAg
ICAgICAgICAgICAgICAgICAgIHQtY2hlY2tib3gtdHlwZXMpKSkpKQoKICAoZGVmdW4gdC0t
Zm9ybWF0LWNoZWNrYm94IChjaGVja2JveCBpbmZvKQogICAgIkZvcm1hdCBhIENIRUNLQk9Y
IG9wdGlvbiB0byBzdHJpbmcuCgpDSEVDS0JPWCBjYW4gYmUgYG9uJywgYG9mZicsIGB0cmFu
cycsIG9yIGFueXRoaW5nIGVsc2UuClJldHVybnMgYW4gZW1wdHkgc3RyaW5nIGlmIENIRUNL
Qk9YIGlzIG5vdCBvbmUgb2YgdGhlIHRoZXNlIHRocmVlLiIKICAgIChkZWNsYXJlIChmdHlw
ZSAoZnVuY3Rpb24gKHQgcGxpc3QpIHN0cmluZykpCiAgICAoc2lkZS1lZmZlY3QtZnJlZSB0
KSAoaW1wb3J0YW50LXJldHVybi12YWx1ZSB0KSkKICAgIChsZXQgKChhICh0LS1jaGVja2Jv
eCBjaGVja2JveCBpbmZvKSkpCiAgICAgIChjb25jYXQgYSAoYW5kIGEgIiAiKSkpKQogIDs7
IG5hdGl2ZSBjb21wCiAgKG5hdGl2ZS1jb21waWxlICd0LS1jaGVja2JveCkKICAobmF0aXZl
LWNvbXBpbGUgJ3QtLWZvcm1hdC1jaGVja2JveCkpCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLSZndDs4Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgpBRkFDSywgdGhl
IGRlZmF1bHQgdmFsdWUgb2YgYG5hdGl2ZS1jb21wLXNwZWVkJyBpcyAyLiBJbiB0aGlzIGNh
c2UsIHRoZQpiZWhhdmlvciBvZiB0aGUgZm9sbG93aW5nIGNvZGUgaXMgaW5jb25zaXN0ZW50
IHdpdGggdGhhdCBvZiB0aGUKYnl0ZS1jb21waWxlZCBvciBub24tY29tcGlsZWQgY29kZToK
Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZndDs4Jmx0Oy0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tCjs7IG5vcm1hbAoodC0tZm9ybWF0LWNoZWNrYm94IG5pbCBteS9wbGlz
dCkgOzs9Jmd0OyAiIgo7OyBieXRlLWNvZGUKKHQtLWZvcm1hdC1jaGVja2JveCBuaWwgbXkv
cGxpc3QpIDs7PSZndDsgIiIKOzsgc3BlZWQgMQoodC0tZm9ybWF0LWNoZWNrYm94IG5pbCBt
eS9wbGlzdCkgOzs9Jmd0OyAiIgo7OyBzcGVlZCAyCih0LS1mb3JtYXQtY2hlY2tib3ggbmls
IG15L3BsaXN0KSA7Oz0mZ3Q7ICIgIgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7
OCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKT2YgY291cnNlLCB3ZSBjYW4g
bm90aWNlIHRoYXQgdGhlIHR5cGUgZGVjbGFyYXRpb24gZm9yIGB0LS1jaGVja2JveCcgaXMK
cHJvYmxlbWF0aWMgLS0tIGl0cyByZXR1cm4gdHlwZSBzaG91bGQgYmUgKG9yIG51bGwgc3Ry
aW5nKSBpbnN0ZWFkIG9mCnN0cmluZy4gQWZ0ZXIgY29ycmVjdGluZyB0aGlzIG1pc3Rha2Us
IHRoZSBmdW5jdGlvbiB3b3JrcyBwcm9wZXJseSB1bmRlcgpzcGVlZD0yLgoKSW4gQywgd2Ug
Z2VuZXJhbGx5IGF2b2lkIGFnZ3Jlc3NpdmUgb3B0aW1pemF0aW9ucyBiZWNhdXNlIHRoZXkg
Y2FuIGxlYWQKdG8gdW5wcmVkaWN0YWJsZSBiZWhhdmlvci4gV2hhdCBJoa9kIGxpa2UgdG8g
YXNrIGlzIHdoZXRoZXIgc2ltaWxhcgpzaXR1YXRpb25zIGNhbiBvY2N1ciBpbiBFbWFjcyBM
aXNwoa9zIG5hdGl2ZSBjb21waWxhdGlvbiBhcyB3ZWxsIC0tLSBsaWtlCnRoZSBpc3N1ZSBJ
IGVuY291bnRlcmVkIGhlcmU/CgpBbm90aGVyIHF1ZXN0aW9uIGlzIGFib3V0IGBjb21waWxh
dGlvbi1zYWZldHknLiBBcyBJIHVuZGVyc3RhbmQgaXQsIHdoZW4Kc2V0IHRvIDEsIGl0IHBy
ZXZlbnRzIEVtYWNzIGZyb20gY3Jhc2hpbmcgZHVlIHRvIGZhdWx0eQpvcHRpbWl6YXRpb25z
LiBEb2VzIHRoaXMgbWVhbiB0aGUgdmFyaWFibGUgb25seSBndWFyZHMgYWdhaW5zdCB0aGUg
bW9zdApzZXZlcmUgY2FzZXMsIHJhdGhlciB0aGFuIGVuc3VyaW5nIHRoZSBjb3JyZWN0bmVz
cyBvZiBvcHRpbWl6YXRpb25zIGluCmdlbmVyYWw/CgpCZXN0IHJlZ2FyZHMuCjwvcHJlPg==

------=_NextPart_682219D5_13C997E8_0D93638F--

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: "Yue Yi" <include_yy@HIDDEN>
Subject: bug#78394: Acknowledgement (31.0.50; Questions about
 native-comp-speed and type decl)
Message-ID: <handler.78394.B.174706533311194.ack <at> debbugs.gnu.org>
References: <tencent_F01FA7D8F74C389263C89576653B3438E707@HIDDEN>
X-Gnu-PR-Message: ack 78394
X-Gnu-PR-Package: emacs
Reply-To: 78394 <at> debbugs.gnu.org
Date: Mon, 12 May 2025 15:56:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 78394 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
78394: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D78394
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#78394: 31.0.50; Questions about native-comp-speed and type decl
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 12 May 2025 16:17:02 +0000
Resent-Message-ID: <handler.78394.B78394.174706661515294 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: "Yue Yi" <include_yy@HIDDEN>, Andrea Corallo <acorallo@HIDDEN>
Cc: 78394 <at> debbugs.gnu.org
Date: Mon, 12 May 2025 19:16:07 +0300
Message-Id: <867c2l7qk8.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <tencent_F01FA7D8F74C389263C89576653B3438E707@HIDDEN>
 (bug-gnu-emacs@HIDDEN)
References: <tencent_F01FA7D8F74C389263C89576653B3438E707@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=gb18030
Content-Transfer-Encoding: 8bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> Date: Mon, 12 May 2025 23:55:01 +0800
> From:  "Yue Yi" via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
> 
> When modifying an org HTML export backend, I tentatively added type
> annotations to a function to make the code run faster. However, during
> unit testing, byte compilation produced correct results, while native
> compilation did not. Specifically, the following cleaned-up code
> illustrates the issue:
> 
> --------------------------->8<-----------------------------
> (defconst my/plist '(:html-checkbox-type unicode))
> (defconst t-checkbox-types
>   '(( unicode .
>       ((on . "�7�1") (off . "�7�0")
>        (trans . "�7�2")))))
> 
> (let ((native-comp-speed 2))
>   (defun t--checkbox (checkbox info)
>     "Format CHECKBOX into HTML."
>     (declare (ftype (function (t plist) string))
>     (side-effect-free t) (important-return-value t))
>     (cdr (assq checkbox
>                (cdr (assq (plist-get info :html-checkbox-type)
>                           t-checkbox-types)))))
> 
>   (defun t--format-checkbox (checkbox info)
>     "Format a CHECKBOX option to string.
> 
> CHECKBOX can be `on', `off', `trans', or anything else.
> Returns an empty string if CHECKBOX is not one of the these three."
>     (declare (ftype (function (t plist) string))
>     (side-effect-free t) (important-return-value t))
>     (let ((a (t--checkbox checkbox info)))
>       (concat a (and a " "))))
>   ;; native comp
>   (native-compile 't--checkbox)
>   (native-compile 't--format-checkbox))
> --------------------------->8<-----------------------------
> 
> AFACK, the default value of `native-comp-speed' is 2. In this case, the
> behavior of the following code is inconsistent with that of the
> byte-compiled or non-compiled code:
> 
> --------------------------->8<-----------------------------
> ;; normal
> (t--format-checkbox nil my/plist) ;;=> ""
> ;; byte-code
> (t--format-checkbox nil my/plist) ;;=> ""
> ;; speed 1
> (t--format-checkbox nil my/plist) ;;=> ""
> ;; speed 2
> (t--format-checkbox nil my/plist) ;;=> " "
> --------------------------->8<-----------------------------
> 
> Of course, we can notice that the type declaration for `t--checkbox' is
> problematic --- its return type should be (or null string) instead of
> string. After correcting this mistake, the function works properly under
> speed=2.
> 
> In C, we generally avoid aggressive optimizations because they can lead
> to unpredictable behavior. What I��d like to ask is whether similar
> situations can occur in Emacs Lisp��s native compilation as well --- like
> the issue I encountered here?
> 
> Another question is about `compilation-safety'. As I understand it, when
> set to 1, it prevents Emacs from crashing due to faulty
> optimizations. Does this mean the variable only guards against the most
> severe cases, rather than ensuring the correctness of optimizations in
> general?

I hope Andrea (CC'ed) will be able to answer your questions.

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#78394: 31.0.50; Questions about native-comp-speed and type decl
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 31 May 2025 09:18:05 +0000
Resent-Message-ID: <handler.78394.B78394.174868304513420 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: acorallo@HIDDEN
Cc: 78394 <at> debbugs.gnu.org, include_yy@HIDDEN
Date: Sat, 31 May 2025 12:16:23 +0300
Message-Id: <86o6v9rvh4.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <867c2l7qk8.fsf@HIDDEN> (message from Eli Zaretskii on Mon, 12
 May 2025 19:16:07 +0300)
References: <tencent_F01FA7D8F74C389263C89576653B3438E707@HIDDEN>
 <867c2l7qk8.fsf@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=gb18030
Content-Transfer-Encoding: 8bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Ping!  Andrea, could you please answer these questions?

> Cc: 78394 <at> debbugs.gnu.org
> Date: Mon, 12 May 2025 19:16:07 +0300
> From: Eli Zaretskii <eliz@HIDDEN>
> 
> > Date: Mon, 12 May 2025 23:55:01 +0800
> > From:  "Yue Yi" via "Bug reports for GNU Emacs,
> >  the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
> > 
> > When modifying an org HTML export backend, I tentatively added type
> > annotations to a function to make the code run faster. However, during
> > unit testing, byte compilation produced correct results, while native
> > compilation did not. Specifically, the following cleaned-up code
> > illustrates the issue:
> > 
> > --------------------------->8<-----------------------------
> > (defconst my/plist '(:html-checkbox-type unicode))
> > (defconst t-checkbox-types
> >   '(( unicode .
> >       ((on . "�7�1") (off . "�7�0")
> >        (trans . "�7�2")))))
> > 
> > (let ((native-comp-speed 2))
> >   (defun t--checkbox (checkbox info)
> >     "Format CHECKBOX into HTML."
> >     (declare (ftype (function (t plist) string))
> >     (side-effect-free t) (important-return-value t))
> >     (cdr (assq checkbox
> >                (cdr (assq (plist-get info :html-checkbox-type)
> >                           t-checkbox-types)))))
> > 
> >   (defun t--format-checkbox (checkbox info)
> >     "Format a CHECKBOX option to string.
> > 
> > CHECKBOX can be `on', `off', `trans', or anything else.
> > Returns an empty string if CHECKBOX is not one of the these three."
> >     (declare (ftype (function (t plist) string))
> >     (side-effect-free t) (important-return-value t))
> >     (let ((a (t--checkbox checkbox info)))
> >       (concat a (and a " "))))
> >   ;; native comp
> >   (native-compile 't--checkbox)
> >   (native-compile 't--format-checkbox))
> > --------------------------->8<-----------------------------
> > 
> > AFACK, the default value of `native-comp-speed' is 2. In this case, the
> > behavior of the following code is inconsistent with that of the
> > byte-compiled or non-compiled code:
> > 
> > --------------------------->8<-----------------------------
> > ;; normal
> > (t--format-checkbox nil my/plist) ;;=> ""
> > ;; byte-code
> > (t--format-checkbox nil my/plist) ;;=> ""
> > ;; speed 1
> > (t--format-checkbox nil my/plist) ;;=> ""
> > ;; speed 2
> > (t--format-checkbox nil my/plist) ;;=> " "
> > --------------------------->8<-----------------------------
> > 
> > Of course, we can notice that the type declaration for `t--checkbox' is
> > problematic --- its return type should be (or null string) instead of
> > string. After correcting this mistake, the function works properly under
> > speed=2.
> > 
> > In C, we generally avoid aggressive optimizations because they can lead
> > to unpredictable behavior. What I��d like to ask is whether similar
> > situations can occur in Emacs Lisp��s native compilation as well --- like
> > the issue I encountered here?
> > 
> > Another question is about `compilation-safety'. As I understand it, when
> > set to 1, it prevents Emacs from crashing due to faulty
> > optimizations. Does this mean the variable only guards against the most
> > severe cases, rather than ensuring the correctness of optimizations in
> > general?
> 
> I hope Andrea (CC'ed) will be able to answer your questions.
> 
> 
> 
>

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#78394: 31.0.50; Questions about native-comp-speed and type decl
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 28 Jun 2025 08:49:03 +0000
Resent-Message-ID: <handler.78394.B78394.17511005034920 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78394
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: acorallo@HIDDEN
Cc: 78394 <at> debbugs.gnu.org, include_yy@HIDDEN
Received: via spool by 78394-submit <at> debbugs.gnu.org id=B78394.17511005034920
          (code B ref 78394); Sat, 28 Jun 2025 08:49:03 +0000
Received: (at 78394) by debbugs.gnu.org; 28 Jun 2025 08:48:23 +0000
Received: from localhost ([127.0.0.1]:47717 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uVRET-0001H7-Tf
	for submit <at> debbugs.gnu.org; Sat, 28 Jun 2025 04:48:23 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:50678)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1uVRER-0001Fs-Cl
 for 78394 <at> debbugs.gnu.org; Sat, 28 Jun 2025 04:48:20 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1uVREM-0000gb-2y; Sat, 28 Jun 2025 04:48:14 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
 Date; bh=4mFfH8eJuFDWDajpBhwJxqzfgZo42luqGzl7fHRoheE=; b=BTbkOxSgxg/uF0wVhhDq
 y+4+fPkEieZOpWpAvr00oBzVvogqLV4aW9d+tyjNdUNyrOcRh2uQ9XzIpKBYG3KMb4wTpWLPxpCfN
 nI4vrB9r1TWzUS0yuvswHgnVPOq/YwYyZIJqyvVzZhzKWMKmMk4FaDJAFod/14s+W8Fl7ZJQgSNGj
 9FSL809lHXjV8Sko/i0h+wMUd09YaKaTr/vFBMDXamTbAXnvB2UNsjPwxB3qWO03FUl8pCLfWuQvW
 kgCtBRvOde7q/R1ik+kS3p+KmyUfnSZP85b6baQA+WKP3dtWdAAxQysi++DIATK313Pky/zrRnN+u
 WEEJewb1sXSZ3Q==;
Date: Sat, 28 Jun 2025 11:48:11 +0300
Message-Id: <86h6008d6c.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <86o6v9rvh4.fsf@HIDDEN> (message from Eli Zaretskii on Sat, 31
 May 2025 12:16:23 +0300)
References: <tencent_F01FA7D8F74C389263C89576653B3438E707@HIDDEN>
 <867c2l7qk8.fsf@HIDDEN> <86o6v9rvh4.fsf@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=gb18030
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Ping! Ping!  Andrea, could you please respond?

> Cc: 78394 <at> debbugs.gnu.org, include_yy@HIDDEN
> Date: Sat, 31 May 2025 12:16:23 +0300
> From: Eli Zaretskii <eliz@HIDDEN>
> 
> Ping!  Andrea, could you please answer these questions?
> 
> > Cc: 78394 <at> debbugs.gnu.org
> > Date: Mon, 12 May 2025 19:16:07 +0300
> > From: Eli Zaretskii <eliz@HIDDEN>
> > 
> > > Date: Mon, 12 May 2025 23:55:01 +0800
> > > From:  "Yue Yi" via "Bug reports for GNU Emacs,
> > >  the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
> > > 
> > > When modifying an org HTML export backend, I tentatively added type
> > > annotations to a function to make the code run faster. However, during
> > > unit testing, byte compilation produced correct results, while native
> > > compilation did not. Specifically, the following cleaned-up code
> > > illustrates the issue:
> > > 
> > > --------------------------->8<-----------------------------
> > > (defconst my/plist '(:html-checkbox-type unicode))
> > > (defconst t-checkbox-types
> > >   '(( unicode .
> > >       ((on . "�7�1") (off . "�7�0")
> > >        (trans . "�7�2")))))
> > > 
> > > (let ((native-comp-speed 2))
> > >   (defun t--checkbox (checkbox info)
> > >     "Format CHECKBOX into HTML."
> > >     (declare (ftype (function (t plist) string))
> > >     (side-effect-free t) (important-return-value t))
> > >     (cdr (assq checkbox
> > >                (cdr (assq (plist-get info :html-checkbox-type)
> > >                           t-checkbox-types)))))
> > > 
> > >   (defun t--format-checkbox (checkbox info)
> > >     "Format a CHECKBOX option to string.
> > > 
> > > CHECKBOX can be `on', `off', `trans', or anything else.
> > > Returns an empty string if CHECKBOX is not one of the these three."
> > >     (declare (ftype (function (t plist) string))
> > >     (side-effect-free t) (important-return-value t))
> > >     (let ((a (t--checkbox checkbox info)))
> > >       (concat a (and a " "))))
> > >   ;; native comp
> > >   (native-compile 't--checkbox)
> > >   (native-compile 't--format-checkbox))
> > > --------------------------->8<-----------------------------
> > > 
> > > AFACK, the default value of `native-comp-speed' is 2. In this case, the
> > > behavior of the following code is inconsistent with that of the
> > > byte-compiled or non-compiled code:
> > > 
> > > --------------------------->8<-----------------------------
> > > ;; normal
> > > (t--format-checkbox nil my/plist) ;;=> ""
> > > ;; byte-code
> > > (t--format-checkbox nil my/plist) ;;=> ""
> > > ;; speed 1
> > > (t--format-checkbox nil my/plist) ;;=> ""
> > > ;; speed 2
> > > (t--format-checkbox nil my/plist) ;;=> " "
> > > --------------------------->8<-----------------------------
> > > 
> > > Of course, we can notice that the type declaration for `t--checkbox' is
> > > problematic --- its return type should be (or null string) instead of
> > > string. After correcting this mistake, the function works properly under
> > > speed=2.
> > > 
> > > In C, we generally avoid aggressive optimizations because they can lead
> > > to unpredictable behavior. What I��d like to ask is whether similar
> > > situations can occur in Emacs Lisp��s native compilation as well --- like
> > > the issue I encountered here?
> > > 
> > > Another question is about `compilation-safety'. As I understand it, when
> > > set to 1, it prevents Emacs from crashing due to faulty
> > > optimizations. Does this mean the variable only guards against the most
> > > severe cases, rather than ensuring the correctness of optimizations in
> > > general?
> > 
> > I hope Andrea (CC'ed) will be able to answer your questions.
> > 
> > 
> > 
> > 
> 
> 
> 
>

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#78394: 31.0.50; Questions about native-comp-speed and type decl
Resent-From: Andrea Corallo <acorallo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 30 Jun 2025 06:17:02 +0000
Resent-Message-ID: <handler.78394.B78394.175126417923998 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78394
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 78394 <at> debbugs.gnu.org, include_yy@HIDDEN
Received: via spool by 78394-submit <at> debbugs.gnu.org id=B78394.175126417923998
          (code B ref 78394); Mon, 30 Jun 2025 06:17:02 +0000
Received: (at 78394) by debbugs.gnu.org; 30 Jun 2025 06:16:19 +0000
Received: from localhost ([127.0.0.1]:37202 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uW7oQ-0006Et-6C
	for submit <at> debbugs.gnu.org; Mon, 30 Jun 2025 02:16:18 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:36538)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <acorallo@HIDDEN>) id 1uW7oO-0006Dy-44
 for 78394 <at> debbugs.gnu.org; Mon, 30 Jun 2025 02:16:16 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <acorallo@HIDDEN>)
 id 1uW7oI-0003bM-MJ; Mon, 30 Jun 2025 02:16:10 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
 From; bh=EQg8fC395tq6AuvXBzApWfNf+P6A8Y9vsqoC7AiFW0g=; b=CmkvUtk3qO9nYydW+wPY
 C8fyc537PPfk5mBLkjxRfMbB2kfG/9lkM2LB+ukIZzCr/PgNJx8KB5iL3ktfsVzRCPOcmdNf+l7QO
 z0pwJb+CtVm2NPAcbpjCfOLwVVf6MD7P7cfg5ubBJ5cPvVuoPmC4PLBb65BtJhNJJ1lBE29gsleAi
 mfq9uzMs6fbQHQpMO7igeiDeDYXfA8PVozD22Vrk0qjmg/M43AEnDKi6/GFVbEzFrEgzU6BLhvkAn
 w7MsVFq/+QPqpuNVTmIX4sHp4lMg1E4PWPUSX/ZQS9/ai7lLCyIqsir6XfutQ0xjcpODv3HWAWZaG
 FIjjkYQReS/NDg==;
Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1)
 (envelope-from <acorallo@HIDDEN>)
 id 1uW7oH-0001ej-SC; Mon, 30 Jun 2025 02:16:10 -0400
From: Andrea Corallo <acorallo@HIDDEN>
In-Reply-To: <86h6008d6c.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 28 Jun
 2025 11:48:11 +0300")
References: <tencent_F01FA7D8F74C389263C89576653B3438E707@HIDDEN>
 <867c2l7qk8.fsf@HIDDEN> <86o6v9rvh4.fsf@HIDDEN>
 <86h6008d6c.fsf@HIDDEN>
Date: Mon, 30 Jun 2025 02:16:09 -0400
Message-ID: <yp1y0t94uvq.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Eli Zaretskii <eliz@HIDDEN> writes:

> Ping! Ping!  Andrea, could you please respond?

Sorry I completely missed this bug.  Looking at it.

  Andrea

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#78394: 31.0.50; Questions about native-comp-speed and type decl
Resent-From: Andrea Corallo <acorallo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 30 Jun 2025 07:33:02 +0000
Resent-Message-ID: <handler.78394.B.175126872730126 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78394
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 78394 <at> debbugs.gnu.org
Cc: include_yy@HIDDEN
X-Debbugs-Original-To: "Yue Yi" via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
X-Debbugs-Original-Cc: 78394 <at> debbugs.gnu.org, Yue Yi <include_yy@HIDDEN>
Received: via spool by submit <at> debbugs.gnu.org id=B.175126872730126
          (code B ref -1); Mon, 30 Jun 2025 07:33:02 +0000
Received: (at submit) by debbugs.gnu.org; 30 Jun 2025 07:32:07 +0000
Received: from localhost ([127.0.0.1]:38289 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uW8zn-0007pn-46
	for submit <at> debbugs.gnu.org; Mon, 30 Jun 2025 03:32:07 -0400
Received: from lists.gnu.org ([2001:470:142::17]:40448)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <acorallo@HIDDEN>) id 1uW8zj-0007oe-C7
 for submit <at> debbugs.gnu.org; Mon, 30 Jun 2025 03:32:04 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10])
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <acorallo@HIDDEN>) id 1uW8zd-0002zM-SN
 for bug-gnu-emacs@HIDDEN; Mon, 30 Jun 2025 03:31:57 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <acorallo@HIDDEN>)
 id 1uW8zZ-0000Di-KF; Mon, 30 Jun 2025 03:31:53 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
 From; bh=9hSAkdoWHPXgEHixBd8wyq7OTQW2RpyzZTR8d0wCEbo=; b=mDwECRYPoWnXkuGSfjNz
 /rgt1JyXbleRRoSOBEW/ES9YHZ+dJAg6tU7Ztyb+wAhpB0wQAhPeOOXr7W0uT8jtiznOruc1qrhg4
 inpIDqsxLJkmKDbc+wfQ+FPwoKY9FZTusSGlkPpFseWEdx1ABOcya/HeJr5iEjZK2qdITk5Jvnmhf
 Bpj0uGC8wmOOSO4SkUKFqOyssROPoTWZD0MF7oyqOj3eLhyMxi+YJsMC8kifWBr0BD6yzZEwviFz+
 bDXH//GDZaXNOO7EbhZnmaWFCd+r0itqMVbZCcI9rJgv3NDGYXz1AfEHwy1plXOChRExrIEO7rUxb
 JR5MSYnfugnI4g==;
Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1)
 (envelope-from <acorallo@HIDDEN>)
 id 1uW8zZ-0007TC-BC; Mon, 30 Jun 2025 03:31:53 -0400
From: Andrea Corallo <acorallo@HIDDEN>
In-Reply-To: <tencent_F01FA7D8F74C389263C89576653B3438E707@HIDDEN> (Yue Yi's
 message of "Mon, 12 May 2025 23:55:01 +0800")
References: <tencent_F01FA7D8F74C389263C89576653B3438E707@HIDDEN>
Date: Mon, 30 Jun 2025 03:31:53 -0400
Message-ID: <yp1tt3x4rdi.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

"Yue Yi" via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@HIDDEN> writes:

> Hello Emacs maintainers,
>
> When modifying an org HTML export backend, I tentatively added type
> annotations to a function to make the code run faster. However, during
> unit testing, byte compilation produced correct results, while native
> compilation did not. Specifically, the following cleaned-up code
> illustrates the issue:
>
> --------------------------->8<-----------------------------
> (defconst my/plist '(:html-checkbox-type unicode))
> (defconst t-checkbox-types
>   '(( unicode .
>       ((on . "=E2=98=92") (off . "=E2=98=91")
>        (trans . "=E2=98=93")))))
>
> (let ((native-comp-speed 2))
>   (defun t--checkbox (checkbox info)
>     "Format CHECKBOX into HTML."
>     (declare (ftype (function (t plist) string))
>     (side-effect-free t) (important-return-value t))
>     (cdr (assq checkbox
>                (cdr (assq (plist-get info :html-checkbox-type)
>                           t-checkbox-types)))))
>
>   (defun t--format-checkbox (checkbox info)
>     "Format a CHECKBOX option to string.
>
> CHECKBOX can be `on', `off', `trans', or anything else.
> Returns an empty string if CHECKBOX is not one of the these three."
>     (declare (ftype (function (t plist) string))
>     (side-effect-free t) (important-return-value t))
>     (let ((a (t--checkbox checkbox info)))
>       (concat a (and a " "))))
>   ;; native comp
>   (native-compile 't--checkbox)
>   (native-compile 't--format-checkbox))
> --------------------------->8<-----------------------------
>
> AFACK, the default value of `native-comp-speed' is 2. In this case, the
> behavior of the following code is inconsistent with that of the
> byte-compiled or non-compiled code:
>
> --------------------------->8<-----------------------------
> ;; normal
> (t--format-checkbox nil my/plist) ;;=3D> ""
> ;; byte-code
> (t--format-checkbox nil my/plist) ;;=3D> ""
> ;; speed 1
> (t--format-checkbox nil my/plist) ;;=3D> ""
> ;; speed 2
> (t--format-checkbox nil my/plist) ;;=3D> " "
> --------------------------->8<-----------------------------
>
> Of course, we can notice that the type declaration for `t--checkbox' is
> problematic --- its return type should be (or null string) instead of
> string. After correcting this mistake, the function works properly under
> speed=3D2.

Hi Yue,

yep that's correct with (declare (ftype (function (t plist) (or string
null)))) it works as expected.

> In C, we generally avoid aggressive optimizations because they can lead
> to unpredictable behavior. What I=E2=80=99d like to ask is whether similar
> situations can occur in Emacs Lisp=E2=80=99s native compilation as well -=
-- like
> the issue I encountered here?

Yep the manual says 'Incorrect type declarations may cause crashes in
natively compiled code'.

> Another question is about `compilation-safety'. As I understand it, when
> set to 1, it prevents Emacs from crashing due to faulty
> optimizations. Does this mean the variable only guards against the most
> severe cases, rather than ensuring the correctness of optimizations in
> general?

The doc for compilation-safety says:

"Possible values are:
  0 - emitted code can misbehave, even crash Emacs, if declarations of
      functions do not correctly describe their actual behavior;
  1 - emitted code is to be generated in a safe manner, even if functions
      are mis-declared."

The situation for 'compilation-safety' with the current code in case of
incorrect declarations is:

0 we perform optimizations, code can even crash.
1 it cannot crash but still we can perform some otimizations (which can
  produce unexpected results at execution time).

If we are unsatisfied with this granularity we could introduce a new value:

2 no optimizations are performed based on function type declarations.

Mmmh maybe is not a bad idea.

  Andrea

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#78394: 31.0.50; Questions about native-comp-speed and type decl
Resent-From: Andrea Corallo <acorallo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 30 Jun 2025 07:33:03 +0000
Resent-Message-ID: <handler.78394.B78394.175126873530195 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78394
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 78394 <at> debbugs.gnu.org
Cc: include_yy@HIDDEN
X-Debbugs-Original-To: "Yue Yi" via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
X-Debbugs-Original-Cc: 78394 <at> debbugs.gnu.org, Yue Yi <include_yy@HIDDEN>
Received: via spool by 78394-submit <at> debbugs.gnu.org id=B78394.175126873530195
          (code B ref 78394); Mon, 30 Jun 2025 07:33:03 +0000
Received: (at 78394) by debbugs.gnu.org; 30 Jun 2025 07:32:15 +0000
Received: from localhost ([127.0.0.1]:38291 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uW8zu-0007qs-Pi
	for submit <at> debbugs.gnu.org; Mon, 30 Jun 2025 03:32:15 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:33502)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <acorallo@HIDDEN>) id 1uW8zj-0007ob-3E
 for 78394 <at> debbugs.gnu.org; Mon, 30 Jun 2025 03:32:07 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <acorallo@HIDDEN>)
 id 1uW8zZ-0000Di-KF; Mon, 30 Jun 2025 03:31:53 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
 From; bh=9hSAkdoWHPXgEHixBd8wyq7OTQW2RpyzZTR8d0wCEbo=; b=mDwECRYPoWnXkuGSfjNz
 /rgt1JyXbleRRoSOBEW/ES9YHZ+dJAg6tU7Ztyb+wAhpB0wQAhPeOOXr7W0uT8jtiznOruc1qrhg4
 inpIDqsxLJkmKDbc+wfQ+FPwoKY9FZTusSGlkPpFseWEdx1ABOcya/HeJr5iEjZK2qdITk5Jvnmhf
 Bpj0uGC8wmOOSO4SkUKFqOyssROPoTWZD0MF7oyqOj3eLhyMxi+YJsMC8kifWBr0BD6yzZEwviFz+
 bDXH//GDZaXNOO7EbhZnmaWFCd+r0itqMVbZCcI9rJgv3NDGYXz1AfEHwy1plXOChRExrIEO7rUxb
 JR5MSYnfugnI4g==;
Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1)
 (envelope-from <acorallo@HIDDEN>)
 id 1uW8zZ-0007TC-BC; Mon, 30 Jun 2025 03:31:53 -0400
From: Andrea Corallo <acorallo@HIDDEN>
In-Reply-To: <tencent_F01FA7D8F74C389263C89576653B3438E707@HIDDEN> (Yue Yi's
 message of "Mon, 12 May 2025 23:55:01 +0800")
References: <tencent_F01FA7D8F74C389263C89576653B3438E707@HIDDEN>
Date: Mon, 30 Jun 2025 03:31:53 -0400
Message-ID: <yp1tt3x4rdi.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

"Yue Yi" via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@HIDDEN> writes:

> Hello Emacs maintainers,
>
> When modifying an org HTML export backend, I tentatively added type
> annotations to a function to make the code run faster. However, during
> unit testing, byte compilation produced correct results, while native
> compilation did not. Specifically, the following cleaned-up code
> illustrates the issue:
>
> --------------------------->8<-----------------------------
> (defconst my/plist '(:html-checkbox-type unicode))
> (defconst t-checkbox-types
>   '(( unicode .
>       ((on . "=E2=98=92") (off . "=E2=98=91")
>        (trans . "=E2=98=93")))))
>
> (let ((native-comp-speed 2))
>   (defun t--checkbox (checkbox info)
>     "Format CHECKBOX into HTML."
>     (declare (ftype (function (t plist) string))
>     (side-effect-free t) (important-return-value t))
>     (cdr (assq checkbox
>                (cdr (assq (plist-get info :html-checkbox-type)
>                           t-checkbox-types)))))
>
>   (defun t--format-checkbox (checkbox info)
>     "Format a CHECKBOX option to string.
>
> CHECKBOX can be `on', `off', `trans', or anything else.
> Returns an empty string if CHECKBOX is not one of the these three."
>     (declare (ftype (function (t plist) string))
>     (side-effect-free t) (important-return-value t))
>     (let ((a (t--checkbox checkbox info)))
>       (concat a (and a " "))))
>   ;; native comp
>   (native-compile 't--checkbox)
>   (native-compile 't--format-checkbox))
> --------------------------->8<-----------------------------
>
> AFACK, the default value of `native-comp-speed' is 2. In this case, the
> behavior of the following code is inconsistent with that of the
> byte-compiled or non-compiled code:
>
> --------------------------->8<-----------------------------
> ;; normal
> (t--format-checkbox nil my/plist) ;;=3D> ""
> ;; byte-code
> (t--format-checkbox nil my/plist) ;;=3D> ""
> ;; speed 1
> (t--format-checkbox nil my/plist) ;;=3D> ""
> ;; speed 2
> (t--format-checkbox nil my/plist) ;;=3D> " "
> --------------------------->8<-----------------------------
>
> Of course, we can notice that the type declaration for `t--checkbox' is
> problematic --- its return type should be (or null string) instead of
> string. After correcting this mistake, the function works properly under
> speed=3D2.

Hi Yue,

yep that's correct with (declare (ftype (function (t plist) (or string
null)))) it works as expected.

> In C, we generally avoid aggressive optimizations because they can lead
> to unpredictable behavior. What I=E2=80=99d like to ask is whether similar
> situations can occur in Emacs Lisp=E2=80=99s native compilation as well -=
-- like
> the issue I encountered here?

Yep the manual says 'Incorrect type declarations may cause crashes in
natively compiled code'.

> Another question is about `compilation-safety'. As I understand it, when
> set to 1, it prevents Emacs from crashing due to faulty
> optimizations. Does this mean the variable only guards against the most
> severe cases, rather than ensuring the correctness of optimizations in
> general?

The doc for compilation-safety says:

"Possible values are:
  0 - emitted code can misbehave, even crash Emacs, if declarations of
      functions do not correctly describe their actual behavior;
  1 - emitted code is to be generated in a safe manner, even if functions
      are mis-declared."

The situation for 'compilation-safety' with the current code in case of
incorrect declarations is:

0 we perform optimizations, code can even crash.
1 it cannot crash but still we can perform some otimizations (which can
  produce unexpected results at execution time).

If we are unsatisfied with this granularity we could introduce a new value:

2 no optimizations are performed based on function type declarations.

Mmmh maybe is not a bad idea.

  Andrea

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#78394: 31.0.50; Questions about native-comp-speed and type decl
Resent-From: "Yue Yi" <include_yy@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 30 Jun 2025 11:35:02 +0000
Resent-Message-ID: <handler.78394.B78394.175128326532574 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78394
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: "Andrea Corallo" <acorallo@HIDDEN>
Cc: Eli&nbsp;Zaretskii <eliz@HIDDEN>, 78394 <78394 <at> debbugs.gnu.org>
Received: via spool by 78394-submit <at> debbugs.gnu.org id=B78394.175128326532574
          (code B ref 78394); Mon, 30 Jun 2025 11:35:02 +0000
Received: (at 78394) by debbugs.gnu.org; 30 Jun 2025 11:34:25 +0000
Received: from localhost ([127.0.0.1]:41445 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uWCmG-0008TB-Fp
	for submit <at> debbugs.gnu.org; Mon, 30 Jun 2025 07:34:25 -0400
Received: from xmbghk7.mail.qq.com ([43.163.128.53]:47471)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <include_yy@HIDDEN>) id 1uWCmA-0008RZ-6h
 for 78394 <at> debbugs.gnu.org; Mon, 30 Jun 2025 07:34:22 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s201512;
 t=1751283243; bh=WWz3tL5XgWsiuhaXSeOy8wPH71F4iJYP/nRh1otWnpY=;
 h=In-Reply-To:References:From:To:Cc:Subject:Date;
 b=SoxwYvHYI2Pa1AeKo8FbMasH2xRyX38TPPA/Bf49zmcKT2X2Mn9TAq3Gi0o4tuw34
 c21zhfIMH482gGHeWKmt5z6FL+ke7JLNPwStBSBnMidIMtLjrLdQPDblh6NDlcRnDX
 TZEgj2MleypExG1IQNxUH+6S3IkQEeV3RZ9tRZ9Q=
X-QQ-FEAT: oHWrrGTW1dCi2Uhv/TjzETR5+gOBkNuu
X-QQ-SSF: 00000000000000F0000000000000
X-QQ-XMRINFO: MSVp+SPm3vtS1Vd6Y4Mggwc=
X-QQ-XMAILINFO: ODP7Xsg997RQ/FCu0YYlTUJUmpUL3v9oQjUBSrlAngVhC1y01SDRaQ3q4G5Vyb
 m5iQTV/75aGU4T3rc/QaFtd8KtehW+TmSri4k3rWopmBjs0l5IBJAPDaNsFBmX8ijMwVBksd3pnhi
 XsvdJ+0YBHn/oeRm1katKlOVJKQ+JVSk/v23la+iWlz3xsMDhbjfl/NbReY6QqnakBjs0CmuerJlE
 Tre7FFEtLnDajFVMd1p3OvsTaiUT60ikQz55lseB0Ryj6BJakNML5JxKRWQYRENSwacf7Id87KyoE
 VqKQ/Tuk9CXDHT3HAZyqPJzeu5chaOLBavquoQzDVa6JflePgcM0c9liwPIH/rKBKKv80o7TuFM5o
 YqBPuqUVpwjSSk4nrzpjsZolIGJDxm+HEgjlnYgEReY6W/YmWEF5YxKMEc3PFL+e0QHna8ADWQmvv
 SICvQe6ixekZuuhGy4UYf+VL6+YGrmXO8vu52r3kUYh3cEXBwlUBNJyNfUxOnf0K6zrUrxrEz+yTp
 WhAvNI9d4UOxhINxVZKF7zYUlxp/YAPYH4Tzn1f++YUIQk6C7N84FItVBF3cLH0cKd45d+tvn6Sem
 HRo0R7wrAXcSB2PBnfMH4xigOynO515zaHmNwYrtJmPfjjP0A56az+Vg6YEIL77qUWSCJIIYMKOc4
 ueHWgZ/+3AjNvIXJqQmXrAzfJVifsiRQQFnCb60mXxO13c0KpO2D8gxnyO7MrVHBVtffQTHTpZDpG
 0lxCodvGmgoJsWNLaXuwjq6fwjTL8OX8MfrREL9lvjjYhW3EsEIYINAWs/pqWLtPv9yqhORb34xJx
 DFJh/h6Ii4yw9DlzJjQA7RFcEo4W/9mu3kguIliA+B5M7VJ30VjIeb8ReVqSMoYYrQjtQvpRGLqcp
 gWrXcBSh+15T0gjdb95PcKu/dM/lYQp8nKNORXsHsbCXdZ6GpLUmIjRbV5X/zVtdq61o/vfK5vYX6
 0+Zz5H6zIrLX6QYA1du0fSIAnQ8n1r17lU9dtwxX3vzIidCXp+ssiY3WTUhnbvBpvuAGkVHKtyH9N
 x5vM7vXUWoIJoNkhOHpJ3nw7Q5/XsoNlmJ1W5
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 183.7.218.64
In-Reply-To: <yp1tt3x4rdi.fsf@HIDDEN>
References: <tencent_F01FA7D8F74C389263C89576653B3438E707@HIDDEN>
 <yp1tt3x4rdi.fsf@HIDDEN>
X-QQ-STYLE: 
X-QQ-mid: webmail739t1751283242t5296205
From: "Yue Yi" <include_yy@HIDDEN>
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="----=_NextPart_6862762A_11089F78_6419F45F"
Content-Transfer-Encoding: 8Bit
Date: Mon, 30 Jun 2025 19:34:02 +0800
X-Priority: 3
Message-ID: <tencent_10379C22DF0FE0208EAB5620952DD0CC9D09@HIDDEN>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

This is a multi-part message in MIME format.

------=_NextPart_6862762A_11089F78_6419F45F
Content-Type: text/plain;
	charset="gb18030"
Content-Transfer-Encoding: base64

VGhhbmtzLCBFbGkgYW5kIEFuZHJlYS4gRGF0ZTogTW9uLCAzMCBKdW4gMjAyNSAwMzozMTo1
MyAtMDQwMCwgQW5kcmVhIENvcmFsbG8gd3JpdGVzLCAmZ3Q7ICZndDsgQW5vdGhlciBxdWVz
dGlvbiBpcyBhYm91dCBgY29tcGlsYXRpb24tc2FmZXR5Jy4gQXMgSSB1bmRlcnN0YW5kIGl0
LCB3aGVuICZndDsgJmd0OyBzZXQgdG8gMSwgaXQgcHJldmVudHMgRW1hY3MgZnJvbSBjcmFz
aGluZyBkdWUgdG8gZmF1bHR5ICZndDsgJmd0OyBvcHRpbWl6YXRpb25zLiBEb2VzIHRoaXMg
bWVhbiB0aGUgdmFyaWFibGUgb25seSBndWFyZHMgYWdhaW5zdCB0aGUgbW9zdCAmZ3Q7ICZn
dDsgc2V2ZXJlIGNhc2VzLCByYXRoZXIgdGhhbiBlbnN1cmluZyB0aGUgY29ycmVjdG5lc3Mg
b2Ygb3B0aW1pemF0aW9ucyBpbiAmZ3Q7ICZndDsgZ2VuZXJhbD8gJmd0OyAgJmd0OyBUaGUg
ZG9jIGZvciBjb21waWxhdGlvbi1zYWZldHkgc2F5czogJmd0OyAgJmd0OyAiUG9zc2libGUg
dmFsdWVzIGFyZTogJmd0OyAgIDAgLSBlbWl0dGVkIGNvZGUgY2FuIG1pc2JlaGF2ZSwgZXZl
biBjcmFzaCBFbWFjcywgaWYgZGVjbGFyYXRpb25zIG9mICZndDsgICAgICAgZnVuY3Rpb25z
IGRvIG5vdCBjb3JyZWN0bHkgZGVzY3JpYmUgdGhlaXIgYWN0dWFsIGJlaGF2aW9yOyAmZ3Q7
ICAgMSAtIGVtaXR0ZWQgY29kZSBpcyB0byBiZSBnZW5lcmF0ZWQgaW4gYSBzYWZlIG1hbm5l
ciwgZXZlbiBpZiBmdW5jdGlvbnMgJmd0OyAgICAgICBhcmUgbWlzLWRlY2xhcmVkLiIgJmd0
OyAgJmd0OyBUaGUgc2l0dWF0aW9uIGZvciAnY29tcGlsYXRpb24tc2FmZXR5JyB3aXRoIHRo
ZSBjdXJyZW50IGNvZGUgaW4gY2FzZSBvZiAmZ3Q7IGluY29ycmVjdCBkZWNsYXJhdGlvbnMg
aXM6ICZndDsgICZndDsgMCB3ZSBwZXJmb3JtIG9wdGltaXphdGlvbnMsIGNvZGUgY2FuIGV2
ZW4gY3Jhc2guICZndDsgMSBpdCBjYW5ub3QgY3Jhc2ggYnV0IHN0aWxsIHdlIGNhbiBwZXJm
b3JtIHNvbWUgb3RpbWl6YXRpb25zICh3aGljaCBjYW4gJmd0OyAgIHByb2R1Y2UgdW5leHBl
Y3RlZCByZXN1bHRzIGF0IGV4ZWN1dGlvbiB0aW1lKS4gVGhhbmsgeW91IGZvciB0aGUgZXhw
bGFuYXRpb24gLS0gSSBub3cgdW5kZXJzdGFuZCB0aGF0IHdoZW4gYGNvbXBpbGF0aW9uLXNh
ZmV0eScgaXMgc2V0IHRvIDEgKHRoZSBkZWZhdWx0KSwgaXQgZ2VuZXJhdGVzIGNvZGUgaW4g
YSBzYWZlciBtYW5uZXIgdGhhdCBhdm9pZHMgY3Jhc2hlcywgZXZlbiBpZiBmdW5jdGlvbiBk
ZWNsYXJhdGlvbnMgYXJlIGluY29ycmVjdC4gSG93ZXZlciwgaXQgZG9lcyAqbm90KiBndWFy
YW50ZWUgdGhlIGNvcnJlY3RuZXNzIG9mIHRoZSBnZW5lcmF0ZWQgY29kZSBpbiBzdWNoIGNh
c2VzLiAmZ3Q7IElmIHdlIGFyZSB1bnNhdGlzZmllZCB3aXRoIHRoaXMgZ3JhbnVsYXJpdHkg
d2UgY291bGQgaW50cm9kdWNlIGEgbmV3IHZhbHVlOiAmZ3Q7ICAmZ3Q7IDIgbm8gb3B0aW1p
emF0aW9ucyBhcmUgcGVyZm9ybWVkIGJhc2VkIG9uIGZ1bmN0aW9uIHR5cGUgZGVjbGFyYXRp
b25zLiAmZ3Q7ICAmZ3Q7IE1tbWggbWF5YmUgaXMgbm90IGEgYmFkIGlkZWEuIE1tbSwgSSBz
b21ld2hhdCBhZ3JlZSB3aXRoIHRoaXMgaWRlYS4gSSBhY3R1YWxseSBkaXNjb3ZlcmVkIHRo
ZSBjb25zZXF1ZW5jZXMgb2YgaW5jb3JyZWN0IHR5cGUgZGVjbGFyYXRpb25zIHdoaWxlIHJ1
bm5pbmcgY29kZSB1bmRlciBFUlQgdGVzdHMsIGJ1dCBpdKGvcyBhIGtpbmQgb2YgaXNzdWUg
dGhhdCdzIG5vdCBpbW1lZGlhdGVseSBvYnZpb3VzIGFzIGJlaW5nIGNhdXNlZCBieSBhIG1p
c2RlY2xhcmVkIHR5cGUuIElmIGFkZGluZyB0aGlzIG9wdGlvbiB3b3VsZG6hr3QgYmUgdG9v
IG11Y2ggdHJvdWJsZSwgcGxlYXNlIGNvbnNpZGVyIGltcGxlbWVudGluZyBpdC4gVElBISBC
eSB0aGUgd2F5LCB3b3VsZCBpbnRyb2R1Y2luZyB0aGlzIG9wdGlvbiBhZmZlY3QgbmF0aXZl
LWNvbXAtc3BlZWQ/IFNpbmNlIGlmIHdlIGhhZCBhIHBvc3NpYmxlIHZhbHVlIG9mIDIsIG9w
dGltaXphdGlvbnMgd291bGRuoa90IHJlbHkgb24gdHlwZSBkZWNsYXJhdGlvbnMgYW55bW9y
ZS4gQW5vdGhlciBwb3NzaWJsZSBpbXByb3ZlbWVudCBtaWdodCBiZSB0byBjbGFyaWZ5IHRo
ZSBkb2NzdHJpbmcgZm9yIGNvbXBpbGF0aW9uLXNhZmV0eS4gSSBtZWFuLCBtYWtpbmcgaXQg
bW9yZSBleHBsaWNpdGx5IHN0YXRlIHRoYXQgaXQgZW5zdXJlcyAqc2FmZXR5KiwgYnV0IGRv
ZXMgbm90IGd1YXJhbnRlZSAqY29ycmVjdG5lc3MqLg==

------=_NextPart_6862762A_11089F78_6419F45F
Content-Type: text/html;
	charset="gb18030"
Content-Transfer-Encoding: base64

PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNo
YXJzZXQ9R0IxODAzMCI+PHByZT5UaGFua3MsIEVsaSBhbmQgQW5kcmVhLgoKRGF0ZTogTW9u
LCAzMCBKdW4gMjAyNSAwMzozMTo1MyAtMDQwMCwgQW5kcmVhIENvcmFsbG8gd3JpdGVzLAoK
Jmd0OyAmZ3Q7IEFub3RoZXIgcXVlc3Rpb24gaXMgYWJvdXQgYGNvbXBpbGF0aW9uLXNhZmV0
eScuIEFzIEkgdW5kZXJzdGFuZCBpdCwgd2hlbgomZ3Q7ICZndDsgc2V0IHRvIDEsIGl0IHBy
ZXZlbnRzIEVtYWNzIGZyb20gY3Jhc2hpbmcgZHVlIHRvIGZhdWx0eQomZ3Q7ICZndDsgb3B0
aW1pemF0aW9ucy4gRG9lcyB0aGlzIG1lYW4gdGhlIHZhcmlhYmxlIG9ubHkgZ3VhcmRzIGFn
YWluc3QgdGhlIG1vc3QKJmd0OyAmZ3Q7IHNldmVyZSBjYXNlcywgcmF0aGVyIHRoYW4gZW5z
dXJpbmcgdGhlIGNvcnJlY3RuZXNzIG9mIG9wdGltaXphdGlvbnMgaW4KJmd0OyAmZ3Q7IGdl
bmVyYWw/CiZndDsgCiZndDsgVGhlIGRvYyBmb3IgY29tcGlsYXRpb24tc2FmZXR5IHNheXM6
CiZndDsgCiZndDsgIlBvc3NpYmxlIHZhbHVlcyBhcmU6CiZndDsgICAwIC0gZW1pdHRlZCBj
b2RlIGNhbiBtaXNiZWhhdmUsIGV2ZW4gY3Jhc2ggRW1hY3MsIGlmIGRlY2xhcmF0aW9ucyBv
ZgomZ3Q7ICAgICAgIGZ1bmN0aW9ucyBkbyBub3QgY29ycmVjdGx5IGRlc2NyaWJlIHRoZWly
IGFjdHVhbCBiZWhhdmlvcjsKJmd0OyAgIDEgLSBlbWl0dGVkIGNvZGUgaXMgdG8gYmUgZ2Vu
ZXJhdGVkIGluIGEgc2FmZSBtYW5uZXIsIGV2ZW4gaWYgZnVuY3Rpb25zCiZndDsgICAgICAg
YXJlIG1pcy1kZWNsYXJlZC4iCiZndDsgCiZndDsgVGhlIHNpdHVhdGlvbiBmb3IgJ2NvbXBp
bGF0aW9uLXNhZmV0eScgd2l0aCB0aGUgY3VycmVudCBjb2RlIGluIGNhc2Ugb2YKJmd0OyBp
bmNvcnJlY3QgZGVjbGFyYXRpb25zIGlzOgomZ3Q7IAomZ3Q7IDAgd2UgcGVyZm9ybSBvcHRp
bWl6YXRpb25zLCBjb2RlIGNhbiBldmVuIGNyYXNoLgomZ3Q7IDEgaXQgY2Fubm90IGNyYXNo
IGJ1dCBzdGlsbCB3ZSBjYW4gcGVyZm9ybSBzb21lIG90aW1pemF0aW9ucyAod2hpY2ggY2Fu
CiZndDsgICBwcm9kdWNlIHVuZXhwZWN0ZWQgcmVzdWx0cyBhdCBleGVjdXRpb24gdGltZSku
CgpUaGFuayB5b3UgZm9yIHRoZSBleHBsYW5hdGlvbiAtLSBJIG5vdyB1bmRlcnN0YW5kIHRo
YXQgd2hlbgpgY29tcGlsYXRpb24tc2FmZXR5JyBpcyBzZXQgdG8gMSAodGhlIGRlZmF1bHQp
LCBpdCBnZW5lcmF0ZXMgY29kZSBpbiBhCnNhZmVyIG1hbm5lciB0aGF0IGF2b2lkcyBjcmFz
aGVzLCBldmVuIGlmIGZ1bmN0aW9uIGRlY2xhcmF0aW9ucyBhcmUKaW5jb3JyZWN0LiBIb3dl
dmVyLCBpdCBkb2VzICpub3QqIGd1YXJhbnRlZSB0aGUgY29ycmVjdG5lc3Mgb2YgdGhlCmdl
bmVyYXRlZCBjb2RlIGluIHN1Y2ggY2FzZXMuCgomZ3Q7IElmIHdlIGFyZSB1bnNhdGlzZmll
ZCB3aXRoIHRoaXMgZ3JhbnVsYXJpdHkgd2UgY291bGQgaW50cm9kdWNlIGEgbmV3IHZhbHVl
OgomZ3Q7IAomZ3Q7IDIgbm8gb3B0aW1pemF0aW9ucyBhcmUgcGVyZm9ybWVkIGJhc2VkIG9u
IGZ1bmN0aW9uIHR5cGUgZGVjbGFyYXRpb25zLgomZ3Q7IAomZ3Q7IE1tbWggbWF5YmUgaXMg
bm90IGEgYmFkIGlkZWEuCgpNbW0sIEkgc29tZXdoYXQgYWdyZWUgd2l0aCB0aGlzIGlkZWEu
IEkgYWN0dWFsbHkgZGlzY292ZXJlZCB0aGUKY29uc2VxdWVuY2VzIG9mIGluY29ycmVjdCB0
eXBlIGRlY2xhcmF0aW9ucyB3aGlsZSBydW5uaW5nIGNvZGUgdW5kZXIgRVJUCnRlc3RzLCBi
dXQgaXShr3MgYSBraW5kIG9mIGlzc3VlIHRoYXQncyBub3QgaW1tZWRpYXRlbHkgb2J2aW91
cyBhcyBiZWluZwpjYXVzZWQgYnkgYSBtaXNkZWNsYXJlZCB0eXBlLiBJZiBhZGRpbmcgdGhp
cyBvcHRpb24gd291bGRuoa90IGJlIHRvbwptdWNoIHRyb3VibGUsIHBsZWFzZSBjb25zaWRl
ciBpbXBsZW1lbnRpbmcgaXQuIFRJQSEKCkJ5IHRoZSB3YXksIHdvdWxkIGludHJvZHVjaW5n
IHRoaXMgb3B0aW9uIGFmZmVjdCBuYXRpdmUtY29tcC1zcGVlZD8KU2luY2UgaWYgd2UgaGFk
IGEgcG9zc2libGUgdmFsdWUgb2YgMiwgb3B0aW1pemF0aW9ucyB3b3VsZG6hr3QgcmVseSBv
bgp0eXBlIGRlY2xhcmF0aW9ucyBhbnltb3JlLgoKQW5vdGhlciBwb3NzaWJsZSBpbXByb3Zl
bWVudCBtaWdodCBiZSB0byBjbGFyaWZ5IHRoZSBkb2NzdHJpbmcgZm9yCmNvbXBpbGF0aW9u
LXNhZmV0eS4gSSBtZWFuLCBtYWtpbmcgaXQgbW9yZSBleHBsaWNpdGx5IHN0YXRlIHRoYXQg
aXQKZW5zdXJlcyAqc2FmZXR5KiwgYnV0IGRvZXMgbm90IGd1YXJhbnRlZSAqY29ycmVjdG5l
c3MqLgo8L3ByZT4=

------=_NextPart_6862762A_11089F78_6419F45F--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#78394: 31.0.50; Questions about native-comp-speed and type decl
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 01 Jul 2025 11:19:02 +0000
Resent-Message-ID: <handler.78394.B78394.17513687224973 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78394
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: "Yue Yi" <include_yy@HIDDEN>
Cc: acorallo@HIDDEN, 78394 <at> debbugs.gnu.org
Received: via spool by 78394-submit <at> debbugs.gnu.org id=B78394.17513687224973
          (code B ref 78394); Tue, 01 Jul 2025 11:19:02 +0000
Received: (at 78394) by debbugs.gnu.org; 1 Jul 2025 11:18:42 +0000
Received: from localhost ([127.0.0.1]:55324 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uWZ0b-0001I5-Dr
	for submit <at> debbugs.gnu.org; Tue, 01 Jul 2025 07:18:42 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:60326)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1uWZ0X-0001Gu-O3
 for 78394 <at> debbugs.gnu.org; Tue, 01 Jul 2025 07:18:38 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1uWZ0R-0003DL-V2; Tue, 01 Jul 2025 07:18:31 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
 Date; bh=jnhBjo0FIdQkaDYGlRCTS9v+zGGv38Aq/Y+nvlb9kxk=; b=ORDQzYFZZ+Um+zwrd7uV
 SjxfQBoU52MGVFayFb82fuszaoSMVCAVMhwcSnRrxCu9y4jrGiS/zkQt8JfUEDJD8d+9q0T/KqoEa
 N9OhYzEtxQtny2Swuf08bwHOTgLcooVvk2bEUUi1eNgRoOfuY59NzS+IzYoWinqJOZf+y4UWoTqc5
 w4h0ej5zUIDVKIDfVDeRkDhVLTyVkSGj3M/DYFWe8IwnktSpynxMIpN4DmMFa8Do6ikiLPvgcP9Oi
 EmnZCs+mJpHAXoInyhZhgCqldbXjU29deOAO6mTQ4taNpS+/Pq0ADPBxNLuynAPc+oSR4H5Hf6Tra
 1hEsaSNSTaLFLQ==;
Date: Tue, 01 Jul 2025 14:18:28 +0300
Message-Id: <86ms9o2m7v.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <tencent_10379C22DF0FE0208EAB5620952DD0CC9D09@HIDDEN>
 (include_yy@HIDDEN)
References: <tencent_F01FA7D8F74C389263C89576653B3438E707@HIDDEN>
 <yp1tt3x4rdi.fsf@HIDDEN>
 <tencent_10379C22DF0FE0208EAB5620952DD0CC9D09@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=gb18030
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: "Yue Yi" <include_yy@HIDDEN>
> Cc: "78394" <78394 <at> debbugs.gnu.org>, "Eli&nbsp;Zaretskii" <eliz@HIDDEN>
> Date: Mon, 30 Jun 2025 19:34:02 +0800
> 
> > "Possible values are:
> >   0 - emitted code can misbehave, even crash Emacs, if declarations of
> >       functions do not correctly describe their actual behavior;
> >   1 - emitted code is to be generated in a safe manner, even if functions
> >       are mis-declared."
> > 
> > The situation for 'compilation-safety' with the current code in case of
> > incorrect declarations is:
> > 
> > 0 we perform optimizations, code can even crash.
> > 1 it cannot crash but still we can perform some otimizations (which can
> >   produce unexpected results at execution time).
> 
> Thank you for the explanation -- I now understand that when
> `compilation-safety' is set to 1 (the default), it generates code in a
> safer manner that avoids crashes, even if function declarations are
> incorrect. However, it does *not* guarantee the correctness of the
> generated code in such cases.
> 
> > If we are unsatisfied with this granularity we could introduce a new value:
> > 
> > 2 no optimizations are performed based on function type declarations.
> > 
> > Mmmh maybe is not a bad idea.
> 
> Mmm, I somewhat agree with this idea. I actually discovered the
> consequences of incorrect type declarations while running code under ERT
> tests, but it��s a kind of issue that's not immediately obvious as being
> caused by a misdeclared type. If adding this option wouldn��t be too
> much trouble, please consider implementing it. TIA!

Patches to implement it are welcome, but I tend to think this
enhancement is not very important.  After all, producing incorrect
code when the programmer provides wrong information is not unexpected,
and the fix is easy.

> Another possible improvement might be to clarify the docstring for
> compilation-safety. I mean, making it more explicitly state that it
> ensures *safety*, but does not guarantee *correctness*.

"Safe" indeed doesn't mean "correct", but I added that nit to the doc
string.

Last modified: Tue, 1 Jul 2025 11:30:04 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.