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) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 4EAE51F4CC for ; Fri, 20 Dec 2024 18:17:01 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; unprotected) header.d=ml.ruby-lang.org header.i=@ml.ruby-lang.org header.a=rsa-sha256 header.s=mail header.b=QGAHUQRF; 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=CrhShDuK; dkim-atps=neutral DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ml.ruby-lang.org; s=mail; t=1734718618; bh=VglPhv6/J+PsqqCucDga+VqJHqKtr7bHAHK2Ilz0AWk=; 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=QGAHUQRFIINRuoCM4zbsBQAWMrYamQfi3DjB7g0XFYRAnhUa2VNac4Y60yNABW/Bp 6cZlTTz4snvJAl9XkyKTzn1TVY9OICOWmSJYQSrDWP6FlvxmudurgF7y7tzyEp1smv b9t6LvtBqz98O6pmb9RFcGsoXDj3UqKxcnE7ldOk= Received: from nue.mailmanlists.eu (localhost [IPv6:::1]) by nue.mailmanlists.eu (Postfix) with ESMTP id C832844F07 for ; Fri, 20 Dec 2024 18:16:58 +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=CrhShDuK; dkim-atps=neutral Received: from s.wrqvtvvn.outbound-mail.sendgrid.net (s.wrqvtvvn.outbound-mail.sendgrid.net [149.72.120.130]) by nue.mailmanlists.eu (Postfix) with ESMTPS id 4CAAE44E8E for ; Fri, 20 Dec 2024 18:16:55 +0000 (UTC) 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=kp9BU9FGZjKi4QOrLJuxuCUrttyVvCHVPvdvgIDA5oA=; b=CrhShDuKu8JSDXalsRhob+YMVxkASWpFxgINWK7Y05qYgjj/rzrAu5D7cq0PjqiispFP Tva4j4d5jPi+ri+Q+eh6zXoxRT1DhZCvipEThnCE6+8dpAKrkDm9vpbv/zBxJjyWD84GIJ Ts4RXwlyuCkSv6imcRcuLQiLyP4XDVxKkNPF0t96rarralmOAI3k0a7308/8aVAG+N6Ud2 rAuOg4euyr4qhSGDK4vEhfIP1dIzFlOvmKmP+9qLk5s5iSRiawvkrYFHpUF+EPQmyQf7PX s2el+1VE8eHb1D2K2Xq8qagxoq3na9DVw5DG6YNJkPODuAbdD+sELEHMmoGSI7pw== Received: by recvd-5c8ccdbd88-98gb2 with SMTP id recvd-5c8ccdbd88-98gb2-1-6765B496-1 2024-12-20 18:16:54.009931604 +0000 UTC m=+3099292.204009758 Received: from herokuapp.com (unknown) by geopod-ismtpd-24 (SG) with ESMTP id DcmEgNTHT7OjE_oQFpIM_A for ; Fri, 20 Dec 2024 18:16:53.980 +0000 (UTC) Date: Fri, 20 Dec 2024 18:16:54 +0000 (UTC) Message-ID: References: Mime-Version: 1.0 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Bug X-Redmine-Issue-Id: 20970 X-Redmine-Issue-Author: tompng X-Redmine-Issue-Priority: Normal X-Redmine-Sender: alanwu 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: 97025 X-SG-EID: =?us-ascii?Q?u001=2EYthNhoKkR+ru7duuIBCSWggX1QviTpo1BTmObZjYMiu+oRLYmEDXRfIb7?= =?us-ascii?Q?CNytBX3Z1NzrRLrrRADZUsP0ba42TZ4z4mt3dcC?= =?us-ascii?Q?BA8B145XquY7uDJ0=2FtetWyj0rYKSa6r6eMtcW+h?= =?us-ascii?Q?uYBEUHJ=2FvHHni963WjeeZPtIJW3pcY7LFlrgXq6?= =?us-ascii?Q?urnZJGq3SVU8D3Mk0O0c1wMJFMVqqexTmL+Zb0p?= =?us-ascii?Q?XUCI4ZB6q0+tCDgCiWPzj=2FJJSFp=2FTHtTHSh9d+1?= =?us-ascii?Q?LMq8?= To: ruby-core@ml.ruby-lang.org X-Entity-ID: u001.I8uzylDtAfgbeCOeLBYDww== Message-ID-Hash: 274VZ5JUF7MAH2HZBC2FT2572LIMQ7IH X-Message-ID-Hash: 274VZ5JUF7MAH2HZBC2FT2572LIMQ7IH 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.9 Precedence: list Reply-To: Ruby developers Subject: [ruby-core:120348] [Ruby master Bug#20970] `it /1/i` raises undefined method 'it' for main (NoMethodError) even if binding.local_variables includes `it` List-Id: Ruby developers Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: "alanwu (Alan Wu) via ruby-core" Cc: "alanwu (Alan Wu)" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Issue #20970 has been updated by alanwu (Alan Wu). Assignee deleted (prism) Sorry, I was too quick to blame Prism. I agree that having `it` as a local brings hidden semantic complexity that warrent discussion. Whether an identifier is a local influences parsing, so it's important to know exactly when `it` becomes a local to the parser. Usually, assignments make locals, but the way parse.y has it currently, `it` becomes a local on read, so in the OP example the first `it` essentially does `it => it` (not `it = it` because that always sets nil) implicitly to influence lines below it. It's a sort of promotion-on-first-read, if you will, a brand new way to add a local in the grammar. It can be hard to parse code mentally and know that whether an `it` is reading a variable and promoting. To illustrate: ```ruby i=2 42.tap do p it /1/i rescue 0 # `it` treated as method call p it /1/i # NoMethodError under parse.y(e23a60b92) surprising if you expect first `it` to refer to a variable end ``` Essentially, with the promote-to-local-on-first-use behavior, the ambiguity inherent to the design of `it` infects subsequent lines in the same scope. (Maybe this is the same point raised in [[ruby-core:120326]](https://bugs.ruby-lang.org/issues/20965#note-6)) @k0kubun @nobu I feel commit:46fec0f62a1803d44edb8b06e39ac0f358e56670 makes a semantic change maybe too close to the release date. Do we really want this right now? How about a narrower fix for #20955? It's fair enough to say "just don't write code that trigger parse warnings", but it's worth thinking through the details of the design, I think. ---------------------------------------- Bug #20970: `it /1/i` raises undefined method 'it' for main (NoMethodError) even if binding.local_variables includes `it` https://bugs.ruby-lang.org/issues/20970#change-111125 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 3.4.0dev (2024-12-19T07:16:12Z master 335bba0fde) +PRISM [x86_64-linux] * Backport: 3.1: DONTNEED, 3.2: DONTNEED, 3.3: DONTNEED ---------------------------------------- `it` parameter became a local variable with #20965, but it does not behave like local variable with `--parser=prism` ~~~ruby i=2 42.tap do p it # 42 p local_variables # [:it, :i] p it /1/i # should be 21, got NoMethodError end ~~~ It prints `42`, `[:it, :i], `21` with `--parser=parse.y` -- 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/lists/ruby-core.ml.ruby-lang.org/