From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jimmy Wong Newsgroups: gmane.emacs.bugs Subject: bug#63564: 29.0.91; (setcdr) behaves differently between natively and byte compiled code Date: Thu, 18 May 2023 18:45:01 +0100 Message-ID: <382e9fc0-c016-49a6-8341-e7bc2c90394c@Spark> References: <83pm6yw2tu.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="64666422_6c13f414_b973" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4576"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 63564@debbugs.gnu.org To: Eli Zaretskii , Andrea Corallo , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu May 18 19:46:13 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pzhhd-00011n-9R for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 18 May 2023 19:46:13 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pzhhV-0000Td-FT; Thu, 18 May 2023 13:46:05 -0400 Original-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 ) id 1pzhhT-0000TP-Cg for bug-gnu-emacs@gnu.org; Thu, 18 May 2023 13:46:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pzhhT-0000LY-59 for bug-gnu-emacs@gnu.org; Thu, 18 May 2023 13:46:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pzhhS-0001UL-It for bug-gnu-emacs@gnu.org; Thu, 18 May 2023 13:46:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jimmy Wong Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 18 May 2023 17:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63564 X-GNU-PR-Package: emacs Original-Received: via spool by 63564-submit@debbugs.gnu.org id=B63564.16844319175666 (code B ref 63564); Thu, 18 May 2023 17:46:02 +0000 Original-Received: (at 63564) by debbugs.gnu.org; 18 May 2023 17:45:17 +0000 Original-Received: from localhost ([127.0.0.1]:54387 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pzhgj-0001TJ-9n for submit@debbugs.gnu.org; Thu, 18 May 2023 13:45:17 -0400 Original-Received: from mail-wr1-f54.google.com ([209.85.221.54]:45428) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pzhgg-0001T3-AX for 63564@debbugs.gnu.org; Thu, 18 May 2023 13:45:15 -0400 Original-Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-30948709b3cso833034f8f.3 for <63564@debbugs.gnu.org>; Thu, 18 May 2023 10:45:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684431908; x=1687023908; h=mime-version:subject:references:in-reply-to:message-id:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=o71YFlWjgyGTxssAtBvAKzSn70xcf96aKrZC9NFTFbw=; b=leZId0FfVOBt+xqSgowVO/kiOS6bUY3/Dv6T31Q5Ln37EhG2VdSRsO1sPy0sEln3Qz WZXBhgVvKu67TRHXvDIVlhXGg6Gt8kTaP8x0G7pUzkC/ULwUVKanXBaXLK+kJ4YOEFh0 E9V+NyxuYuV0hDvZaboipGIe0J8Olv+O/frYydjQaKN2UTOfrIwjoedCD/vK5lbuOgtN W9yroVB5DQOMpHLtoTWE2X4n7yJNh7sdPNTe5kCR6G2g7zUlBXvN4qe8VPGlwgKxmtOL yH3uEIdkHmIwwnxytEtL+009SKht+CZ4ogQJeI40/rCAydkxRCFeaX1Th2YOwqoL0FAT Cgeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684431908; x=1687023908; h=mime-version:subject:references:in-reply-to:message-id:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=o71YFlWjgyGTxssAtBvAKzSn70xcf96aKrZC9NFTFbw=; b=VGaTOcNUhf+YTZ9CZO7sgFvRdNsu8QGparBINwz+IYk9Hiitpcm+2M8c/oVQog3LAW sOJmbgn9Suj+FqQn4VohzC7L4Psft9OR2tHCxO4UOmsK3oi7uHOWPKOzguMBTHiLmlPG fOteMOREcEvtfR0D1EAxcErya/R0jsGGy11u6QdDCXJYtB6g9emixT6yCuviI+bLICt6 aqi9LAWL5rb0IE/nPzjwYUJxTtmdvQIDrdd4E2ZnCn7vqGvzCRKvMGzggKZi1Tkq7+kH rWOG/gTXj4Db2Petde8/glGmFTIz5qH4sK3NhhqpDz0yJJnoO8y/y+RCZGfhi/MqTx9s 1P+w== X-Gm-Message-State: AC+VfDxIqN3+ZjqmpVMDO8kfcZU5rMsB8lYoKWi56lR6bsxP5QfGpUEp Hln5Jush4gDUBoJAbGZUhZc= X-Google-Smtp-Source: ACHHUZ6M0mWkQ+at5pOJrh4ntfLMwBIiuMtYAXRSUYs9fmujB6HKcMDNponC+svsCVr1Pv6QPfeyUQ== X-Received: by 2002:a5d:4bcb:0:b0:306:2cd2:bca8 with SMTP id l11-20020a5d4bcb000000b003062cd2bca8mr2119731wrt.7.1684431908195; Thu, 18 May 2023 10:45:08 -0700 (PDT) Original-Received: from [2a01:4b00:89a0:2400::ffff:ffff] ([2a01:4b00:89a0:2400:301f:207a:a22f:7653]) by smtp.gmail.com with ESMTPSA id b8-20020a5d4d88000000b00304ae802f02sm2823795wru.66.2023.05.18.10.45.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 May 2023 10:45:07 -0700 (PDT) In-Reply-To: X-Readdle-Message-ID: 382e9fc0-c016-49a6-8341-e7bc2c90394c@Spark X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:261949 Archived-At: --64666422_6c13f414_b973 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline As Mattias has noted, this commit on markdown-mode did fix the issues, it would still be nice to know why the natively compiled version behaves differently from the byte compiled version tho. This could be good learning for occasional elisp devs such as myself to know what to watch out for. https://github.com/jrblevin/markdown-mode/commit/44f0e89534e6e5b3e752759d513f4a6f9757b9ee On 18 May 2023 at 8:54 AM +0100, Andrea Corallo , wrote: > Eli Zaretskii writes: > > > > From: Jimmy Yuen Ho Wong > > > Date: Thu, 18 May 2023 03:40:40 +0100 > > > > > > > > > Users have discovered there's a markdown-mode function that behaves > > > differently depending Emacs is executing byte-compiled code or natively > > > compiled code. > > > > > > The issue is documented > > > [here](https://github.com/jrblevin/markdown-mode/issues/578). > > > > > > > > > There are two examples in the issue that will produce an `Wrong type > > > argument: consp, nil` error on the natively compiled version of > > > `markdown-imenu-create-nested-index`, but not the byte-compiled or > > > interpreted version. A user has provided a disassembly of the natively > > > compiled code for that function. > > > > > > The last user has said and I can confirm the offending line seems to be `(setcdr > > > sibling-alist alist)` in that function. > > > > > > Much appreciate it if Andrea could take a look. > > > > Adding Andrea. > > > > While, of course, Andrea's help will be appreciated, there's currently > > no reason to believe this is a problem in the Emacs core, and > > therefore filing a bug report here could be premature. Ideally, the > > markdown-mode's developers should examine the problem first and > > present convincing evidence that this is a problem with native > > compilation and not with the code in markdown-mode itself. > > Yep, if markdown-mode's developers could present a reproducer showing > how exactly the function miss-behaves and where that would help. > > Andrea --64666422_6c13f414_b973 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
As Mattias has noted, this commit on markdown-mode = did fix the issues, it would still be nice to know why the natively compi= led version behaves differently from the byte compiled version tho. This = could be good learning for occasional elisp devs such as myself to know w= hat to watch out for.

https://github.com/jrblevin/markdown-mode/commit/44f0e89534e6e5b3e752759d= 513f4a6f9757b9ee
On 18 May 2023 at 8:54 AM +0100, An= drea Corallo <akrl=40sdf.org>, wrote:
Eli Zaretskii <eliz=40gnu.org> writes:

=46rom: Jimmy Yuen Ho Wong <wyuenho=40gm= ail.com>
Date: Thu, 18 May 2023 03:40:40 +0100


Users have discovered there's a markdown-mode function that behaves
= differently depending Emacs is executing byte-compiled code or natively compiled code.

The issue is documented
=5Bhere=5D(https://github.com/jrblevin/markdown-mode/issues/578).


There are two examples in the issue that will produce an =60Wrong type argument: consp, nil=60 error on the natively compiled version of
=60markdown-imenu-create-nested-index=60, but not the byte-compiled or interpreted version. A user has provided a disassembly of the natively compiled code for that function.

The last user has said and I can confirm the offending line seems to be =60= (setcdr
sibling-alist alist)=60 in that function.

Much appreciate it if Andrea could take a look.

Adding Andrea.

While, of course, Andrea's help will be appreciated, there's currently no reason to believe this is a problem in the Emacs core, and
therefore filing a bug report here could be premature. Ideally, the
= markdown-mode's developers should examine the problem first and
present convincing evidence that this is a problem with native
compilation and not with the code in markdown-mode itself.

Yep, if markdown-mode's developers could present a reproducer showing
how exactly the function miss-behaves and where that would help.

Andrea
--64666422_6c13f414_b973--