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 F19181F5D2 for ; Fri, 14 Mar 2025 09:52:00 +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=quaN9moR; 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=S3Yuf3uS; dkim-atps=neutral DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ml.ruby-lang.org; s=mail; t=1741945887; bh=JoM949SpeycVBHSiIjXHoVpT56e+XtDkM00dfqHtTk8=; 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=quaN9moRExVLBRieMRUI44Yz+IoweH9A3oBnkd/yFUV09Jm/lMrJmTv8Kl63oo31K 1c/9MxGtSB+aj4slZZQpqnWzdTW7eKNvoVNwLL6vNHsRxywVy0IZKKZhTSKCP3+Yuy Oolv2x6eJyARmOeYP4GhpQI77iua0pXB8Eyz502M= Received: from nue.mailmanlists.eu (localhost [IPv6:::1]) by nue.mailmanlists.eu (Postfix) with ESMTP id 88EC346DD3 for ; Fri, 14 Mar 2025 09:51:27 +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=S3Yuf3uS; 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 8BEA946D59 for ; Fri, 14 Mar 2025 09:51:21 +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=aeTkB1SLRE7A2lE69VNgXko+9QW4cAPSUtDnN7h+JEY=; b=S3Yuf3uSaAx/SyvoLGDYjLCTfnsgXK5C+/ZQM7cZXy2X+gd86H/oDj1NTnX9KWYnrHwt mkPwGdn2zFeMeC2yEH0A9OrcQJRLQgIpUa2wOuMHaga//CTSucZtrAw0QDIlKM+qtOYx85 YWmDhGq2YGTiyFeiY7VkDliIQ11JVYoROqczeuKfotXrY091aGhzuATZSM3gpY1gf84ioL pN+Nu0K8cIRfqK8yB7YFblMWnUnvqY0rLOGGm+p3cm+fPXeNutURpHZNIP9KtFtSJkOWvZ 8MrEVE5GNj/yU+qADQOGCTxTKG1Wg3vGU8jxGT9IdHy1ypJe8D2/iMF/8RtrASqQ== Received: by recvd-5f54b5d587-6xg6k with SMTP id recvd-5f54b5d587-6xg6k-1-67D3FC18-B 2025-03-14 09:51:20.198565839 +0000 UTC m=+10326536.637270323 Received: from herokuapp.com (unknown) by geopod-ismtpd-38 (SG) with ESMTP id oRnsqTcEQoiNuelLhP5DFg for ; Fri, 14 Mar 2025 09:51:20.136 +0000 (UTC) Date: Fri, 14 Mar 2025 09:51:20 +0000 (UTC) Message-ID: References: Mime-Version: 1.0 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Misc 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: 98086 X-SG-EID: =?us-ascii?Q?u001=2EByjZWvxTCjdoV8K03xEuhE7KqN4thWULFLM7+oH78KY30oYB3qFthsDpL?= =?us-ascii?Q?4w4cbYa3ttBh8bAHPOnE=2FkzPba67JNu7Lnrked2?= =?us-ascii?Q?O7K9VQ=2FJax11Ls1Eon1NuqMEf0yWR1YxEDxJKLe?= =?us-ascii?Q?jqSNvIx=2FoDJFlff1V9PMvwsqh26UA6k+W8TsJh4?= =?us-ascii?Q?BMYYwEYKfXJ95UQ3Dqnj+2p=2FUtgcr3AUL7UY4Wc?= =?us-ascii?Q?SavL6YM3++3r021rCA4t1rbMXL4sCPdmHzYj=2FUC?= =?us-ascii?Q?fa+4OSPUWg3xPzSGzSsxbLdb3A=3D=3D?= To: ruby-core@ml.ruby-lang.org X-Entity-ID: u001.I8uzylDtAfgbeCOeLBYDww== Message-ID-Hash: Z4XGEGCKAYNJG7IO4JLDLGD6ZQTJBCPE X-Message-ID-Hash: Z4XGEGCKAYNJG7IO4JLDLGD6ZQTJBCPE 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:121362] [Ruby Misc#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). mame (Yusuke Endoh) wrote in #note-15: > In any case, it was reaffirmed that matz strongly prefers that ` If we could show the file and line for C functions, that would be useful for debugging. I assume the only reason we don't is that doing so is not feasible. It should be feasible with a C preprocessor macro using `__FILE__` and `__LINE__`. In fact, I think it's confusing and misleading that methods defined in C report that they are defined in the caller Ruby file (which is obviously incorrect, they are not defined there). Detailed in the 2nd part of [this comment](https://bugs.ruby-lang.org/issues/20968#note-6) after the horizontal line. I think that illustrates clearly that people got used to this "confusing/misleading way to report the stacktrace for C-defined methods", and so they are surprised to see something else for Ruby-defined core methods. But I believe it is just a matter of getting used to it. Passed the initial "surprise" it makes total sense because it's no different than a regular method defined in Ruby code (except the file prefix). [This comment](https://bugs.ruby-lang.org/issues/20968#note-9) demonstrates that the current stacktrace for `Array#fetch_values` is very consistent as if the method was defined in a Ruby file in some gem or so. And on the contrary, changing stacktraces as proposed would introduce a 3rd kind of entry in the backtrace, which I think is evident it will cause more confusion, due to hiding crucial information in at least some cases. --- BTW `' $ 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/