From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on starla X-Spam-Level: X-Spam-Status: No, score=0.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_BL_SPAMCOP_NET,SPF_HELO_PASS, SPF_PASS autolearn=no autolearn_force=no version=3.4.6 Received: from nue.mailmanlists.eu (nue.mailmanlists.eu [94.130.110.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 1EC901F44D for ; Tue, 26 Mar 2024 01:12:35 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; secure) header.d=ml.ruby-lang.org header.i=@ml.ruby-lang.org header.a=rsa-sha256 header.s=mail header.b=wYQQ04J9; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=ruby-lang.org header.i=@ruby-lang.org header.a=rsa-sha256 header.s=s1 header.b=GIkxyIjy; dkim-atps=neutral Received: from nue.mailmanlists.eu (localhost [127.0.0.1]) by nue.mailmanlists.eu (Postfix) with ESMTP id 88FC083846; Tue, 26 Mar 2024 01:12:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ml.ruby-lang.org; s=mail; t=1711415548; bh=7oCmHZ0UqTloyVGbO5mgssXoTSKlgi+tjGnZT/79bqE=; h=Date:References:To:Reply-To:Subject:List-Id:List-Archive: List-Help:List-Owner:List-Post:List-Subscribe:List-Unsubscribe: From:Cc:From; b=wYQQ04J9SQ1UU/SauimUtkl2kHGHzjcrKe+jXIAimWynWGemiin3ZXdRdEZ8tQPsu MZVuFWFWMxaQGgLbY/+2Wb6I7q8tdAhxjK76KzPDFwGUrKGupq8Z3scARhrcGhfDFV ga/JMPSnW0e1Fxy0oGcIdnK6qAVW9GJiyVGjL/aA= Received: from s.wrqvtzvf.outbound-mail.sendgrid.net (s.wrqvtzvf.outbound-mail.sendgrid.net [149.72.126.143]) by nue.mailmanlists.eu (Postfix) with ESMTPS id 90D0883840 for ; Tue, 26 Mar 2024 01:12:24 +0000 (UTC) Authentication-Results: nue.mailmanlists.eu; dkim=pass (2048-bit key; unprotected) header.d=ruby-lang.org header.i=@ruby-lang.org header.a=rsa-sha256 header.s=s1 header.b=GIkxyIjy; dkim-atps=neutral DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ruby-lang.org; h=from:references:subject:mime-version:content-type: content-transfer-encoding:list-id:to:cc:content-type:from:subject:to; s=s1; bh=ylFZqYIR2WtuWyigztXs1kmafogckWfxpO46QH9jygw=; b=GIkxyIjyxYkEWXHQVHtFkD6HP5y3UeYqfgFyR9ySiyVLRYAMHvq9GjN4Kh+lPBCUfSXX oTLwwHugI7iEcY1NMspOCqHQg/+yXfh9QQhG6OJj/84MzNfb+cgviUU/2740iVWMW670Mi U5i90c2NvzoOfqAdWXb9opzoLplc5y7Q8TW9quio9yWcGMMZ+Gb2TR/K+OqV+OUIVftPT1 tnFOIplwEl5T7cfypmDQ+MPN+x6gz/tsfZK3xrx5uPX30cmE+cxr9wjdAsVkEHYHRmjl+k 9ogtz7ZFGHWogXEhE1eeSTxiYoDgAJw4Mz8CWSGT8/KgS6PDWUNT6d1MUDjAxOmQ== Received: by recvd-75c664ffc8-g2jws with SMTP id recvd-75c664ffc8-g2jws-1-660220F6-8 2024-03-26 01:12:22.965934414 +0000 UTC m=+619974.614349385 Received: from herokuapp.com (unknown) by geopod-ismtpd-37 (SG) with ESMTP id m3HEWpYcQJiYiKB_nL80ww for ; Tue, 26 Mar 2024 01:12:22.917 +0000 (UTC) Date: Tue, 26 Mar 2024 01:12:23 +0000 (UTC) Message-ID: References: Mime-Version: 1.0 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Bug X-Redmine-Issue-Id: 20392 X-Redmine-Issue-Author: tenderlovemaking X-Redmine-Issue-Priority: Normal X-Redmine-Sender: nobu X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-Redmine-MailingListIntegration-Message-Ids: 93917 X-SG-EID: =?us-ascii?Q?u001=2E5PtzXJ23KrYzgM1nrOIr+EQ222PyrDaWSg0Er8CZ8tP86xyXmBM81zBKD?= =?us-ascii?Q?HreavdFYMbHjxXOR6UPMkt=2Fu9CyBIp6y52n8D2y?= =?us-ascii?Q?qA9zqurrgUcOPSZVPGkNthjzya89OVEDE2CmJWQ?= =?us-ascii?Q?IBRrKLLIGZVonSBUkeNvOa+JzNK3XY8PM5+IC0T?= =?us-ascii?Q?7BmteDe6QHuRkCBP6X4Bhm2RG1wZRysMXjTZWkN?= =?us-ascii?Q?etEAVgx=2F7WUmf9LjkXUP0Cpghc7EFOua0TAAK8n?= =?us-ascii?Q?xJzcNabdihl=2FhZj8yfiuEmIa4g=3D=3D?= To: ruby-core@ml.ruby-lang.org X-Entity-ID: u001.I8uzylDtAfgbeCOeLBYDww== Message-ID-Hash: XLRWBLDDECOJYYINYRHBYLXMPDT3JPJG X-Message-ID-Hash: XLRWBLDDECOJYYINYRHBYLXMPDT3JPJG X-MailFrom: bounces+313651-b711-ruby-core=ml.ruby-lang.org@em5188.ruby-lang.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.3 Precedence: list Reply-To: Ruby developers Subject: [ruby-core:117319] [Ruby master Bug#20392] Delegate super calls with a block List-Id: Ruby developers Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: "nobu (Nobuyoshi Nakada) via ruby-core" Cc: "nobu (Nobuyoshi Nakada)" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Issue #20392 has been updated by nobu (Nobuyoshi Nakada). jeremyevans0 (Jeremy Evans) wrote in #note-4: > It's missing entries for `NODE_SUPER` and `NODE_ZSUPER` in `get_nd_args`, so the `nd_args` are ignored for those nodes. At least those node types should be fixed, and all other node types in the switch should be checked to see if this isn't swallowing other syntax errors. @yui-knk is my analysis correct? I think that zsuper is special. ---------------------------------------- Bug #20392: Delegate super calls with a block https://bugs.ruby-lang.org/issues/20392#change-107459 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * ruby -v: ruby 3.4.0dev (2024-03-15T18:08:39Z master e3a82d79fd) [arm64-darwin23] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I'm seeing strange behavior with calls to `super` when combined with `...` and a block. I'm not sure if this is expected behavior or not, so I'm filing this ticket. Using delegate `...` with an explicit block will cause an error: ```ruby # Example 1 def foo ... yield end def bar ... foo(...) { } # test.rb: test.rb:6: both block arg and actual block given (SyntaxError) end ``` However, calling `super` and passing a block works: ```ruby # Example 2 class A def foo yield(3) end end class B < A def foo(...) super do |x| yield(2 + x) end end end p B.new.foo { |x| x } # 5 ``` In the above code, I imagine the bare `super` to basically be equivalent of `super(...)` since I defined the method `foo` as `foo(...)`. However, if I explicitly pass `...` to super, there is no syntax error, just the block I provided is ignored: ```ruby # Example 3 class A def foo yield(3) end end class B < A def foo(...) super(...) do |x| raise "should I be called?" end end end p B.new.foo { |x| x } # 3 ``` I'd expect Example 3 to raise an exception like Example 1. Additionally, I think the behavior in Example 2 is odd, but zsupers are "special" so I can understand if it is intended behavior. Is Example 3 intended behavior? If not, how should it behave? Thanks. -- https://bugs.ruby-lang.org/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/