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 28CA01F4EB for ; Tue, 18 Feb 2025 23:19:52 +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=AXqBggiA; 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=g8ywqKFY; dkim-atps=neutral DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ml.ruby-lang.org; s=mail; t=1739920759; bh=Bv2vlsjdCmbv5q2W8g1gT51n2SBCG14d27QinyvAPEE=; 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=AXqBggiAjSHqSsmK+kGT4kb8x0QBaix51fKSE1ncY16P+OfrM2UBdyVJjV/D5KIzg el5pKjCz65JSzGBNIaUylkUkXtGoC2VJZ6VAPc0O+AsszxSkrB6pp7E7AXVydE6XOs v3bj68upjOBUtLXsSP4JVfC9Mj4qyZLXrWERdiVM= Received: from nue.mailmanlists.eu (localhost [IPv6:::1]) by nue.mailmanlists.eu (Postfix) with ESMTP id 8211E469F6 for ; Tue, 18 Feb 2025 23:19:19 +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=g8ywqKFY; dkim-atps=neutral Received: from s.wrqvwxzv.outbound-mail.sendgrid.net (s.wrqvwxzv.outbound-mail.sendgrid.net [149.72.154.232]) by nue.mailmanlists.eu (Postfix) with ESMTPS id D60E5469EA for ; Tue, 18 Feb 2025 23:19:14 +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=ujyJI3UTYJqXgLAf9aALT73D9Ev2SNNwGR4N9MHm2Zo=; b=g8ywqKFYWahi32nrY55prNb11mS2BJi46v3EM/7iMFuV4MEXoZ0UIibv8noKX+dRIs55 Z55XVzKdh1FXjrl3Uq5ssP7d75xKvRF1tTGO//EGDMjTkuYlXDfjkSW2PdQ+1IzCnmwhdF XlPPEMM7taiCktJz9y0+g8OcFyhQlBqO18UDaBUpfgy+OoB27kSZQplgsD/84FL4R0uEx1 Jte7S3YeFA51hnonYmOdifzmZ7xoU53DejenngKK6pXDdbRB3ZD1YMYpnDj6h8xn0mLfzO RiLAQeKGhPQAwdS1p/XZ3C/esXyXEIxM/iNAMhmEPhgKP1RHr2A2NxDvKNQZkIZA== Received: by recvd-786d47b7ff-jbd2f with SMTP id recvd-786d47b7ff-jbd2f-1-67B51571-1D 2025-02-18 23:19:13.689382804 +0000 UTC m=+8301427.759992628 Received: from herokuapp.com (unknown) by geopod-ismtpd-16 (SG) with ESMTP id ge0UkqoITVKzAvdLXl5sQw for ; Tue, 18 Feb 2025 23:19:13.628 +0000 (UTC) Date: Tue, 18 Feb 2025 23:19:13 +0000 (UTC) Message-ID: References: Mime-Version: 1.0 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Bug X-Redmine-Issue-Id: 20968 X-Redmine-Issue-Author: koic X-Redmine-Issue-Priority: Normal X-Redmine-Sender: Eregon 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: 97838 X-SG-EID: =?us-ascii?Q?u001=2EByjZWvxTCjdoV8K03xEuhE7KqN4thWULFLM7+oH78KY30oYB3qFthsDpL?= =?us-ascii?Q?4w4cbYa3ttBh8bAHPOnE=2FkzPba67JNu7Lnrked2?= =?us-ascii?Q?O7K9VQ=2FJax1LRMGgsy9P5=2FwSTnGql2rAO81QNgv?= =?us-ascii?Q?imYPI6kyGsMirNkLO58yJT5O2N0dCE6XJkyvF5a?= =?us-ascii?Q?3jjbM60dwtQutMQeDm9NbX2MAeT5KOz2G03NQMq?= =?us-ascii?Q?vJ1p5ClVR+rS99F4Kr3v=2F=2Fe+D+vCuJ9u2jvBoSV?= =?us-ascii?Q?tZv532kb=2Fp+=2F6FJ9GiFfAdy4wA=3D=3D?= To: ruby-core@ml.ruby-lang.org X-Entity-ID: u001.I8uzylDtAfgbeCOeLBYDww== Message-ID-Hash: OJR3DLZ72J2CJMOPKM6J6KDFMOVM3UP5 X-Message-ID-Hash: OJR3DLZ72J2CJMOPKM6J6KDFMOVM3UP5 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:121116] [Ruby master Bug#20968] `Array#fetch_values` unexpected method name in stack trace List-Id: Ruby developers Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: "Eregon (Benoit Daloze) via ruby-core" Cc: "Eregon (Benoit Daloze)" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Issue #20968 has been updated by Eregon (Benoit Daloze). I think this is mostly a matter of getting used to ` I agree that this is not a bug, but I think koic's expectations are clearly better than the current from a user benefit perspective, not from a consistency perspective. > I think it is significantly unlikely that `:211` is valuable information for user to debug a bug. > It would be more convenient to combine `` backtraces into one and substitute the name of the calling Ruby source file and line number, as in the current C-implemented method. FWIW we considered this (combine internal entries into one, or hiding internal entries, or [attribute all entries to the caller](https://github.com/oracle/truffleruby/issues/1414), etc) in TruffleRuby (it was discussed a few times on the truffleruby issue tracker, since truffleruby has many more methods defined in Ruby) but rejected this idea as it is clearly suboptimal for multiple reasons: * Debugging an issue with a partial backtrace is always worse and more confusing (for both VM developers and users). * Imagine that someone redefines `Array#fetch`. And when used from `fetch_values` it raises some unexpected exception. With the full backtrace like currently the user can easily understand what's going on. Without it, it's very hard. We might see the file which redefines `Array#fetch`, but not if it's redefined in C. And it would be weird for `fetch_values` to have a different number of backtraces entries based on which `fetch` method ends up being called. * As an example for `Hash#[]=`, if that hides the `key.hash` call, and some `hash` method implementation raises, it's way more confusing if the `hash` is not shown in the backtrace. Current: ``` $ ruby -e 'k=Object.new; def k.hash; raise "foo"; end; {}[k] = 1' -e:1:in 'hash': foo (RuntimeError) from -e:1:in '
' ``` vs ``` $ ruby -e 'k=Object.new; def k.hash; raise "foo"; end; {}[k] = 1' -e:1:in '
': foo (RuntimeError) ``` (both of these hide the `[]=` call, that's not great but due to having a special instruction for this, hard to fix without hurting performance) * Another example could be `inject` calling some core method, if we replace the two entries by one it would be very confusing, leading to think that `inject` is raising when it's the core method being called which is raising an exception. * `` is now a well-established format for this for some time already. * The line information could be useful for users too, especially if the editor/IDE would support viewing the source file in such a case. * It is important for reasoning that one Ruby call/frame = one backtrace entry. * In some specific use cases it may make sense to skip `' ``` They are actually "wrong" because `Array#fetch` is not defined in `fetch.rb:1`, it is defined in the core library. I think that has BTW caused some confusion because people might not realize the location on the left should be the definition of the method mentioned on the right (since it doesn't hold for C methods). ---------------------------------------- Bug #20968: `Array#fetch_values` unexpected method name in stack trace https://bugs.ruby-lang.org/issues/20968#change-112038 * Author: koic (Koichi ITO) * Status: Open * ruby -v: ruby 3.4.0dev (2024-12-19T04:44:56Z master 2783868de2) +PRISM [x86_64-darwin23] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- It seems that the current Ruby implementation is displaying unexpected method name in stack trace. ## Expected Similar to `Hash#fetch_values`, the method name `Array#fetch_values` is expected to be displayed in the stack trace. ```console $ ruby -e '{k: 42}.fetch_values(:unknown)' -e:1:in 'Hash#fetch_values': key not found: :unknown (KeyError) from -e:1:in '
' $ ruby -e '[1].fetch_values(42)' -e:1:in 'Array#fetch_values': index 42 outside of array bounds: -1...1 (IndexError) from -e:1:in '
' ``` ## Actual The stack trace displays the `Array#fetch` method, which user is not aware of, along with the `` stack trace. ```console $ ruby -e '[1].fetch_values(42)' :211:in 'Array#fetch': index 42 outside of array bounds: -1...1 (IndexError) from :211:in 'block in Array#fetch_values' from :211:in 'Array#map!' from :211:in 'Array#fetch_values' from -e:1:in '
' ``` It likely requires an approach such as implementing it in C, as suggested in https://github.com/ruby/ruby/pull/11555. -- 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/