[#100309] How to use backport custom field — Jun Aruga <jaruga@...>
Please allow my ignorance.
9 messages
2020/10/06
[#100310] Re: How to use backport custom field
— "NARUSE, Yui" <naruse@...>
2020/10/06
"Backport custom field" is only available for tickets whose tracker is "Bug".
[#100311] Re: How to use backport custom field
— Jun Aruga <jaruga@...>
2020/10/06
On Tue, Oct 6, 2020 at 4:44 PM NARUSE, Yui <naruse@airemix.jp> wrote:
[#100314] Re: How to use backport custom field
— "NARUSE, Yui" <naruse@...>
2020/10/06
Thank you for confirmation.
[#100322] Re: How to use backport custom field
— Jun Aruga <jaruga@...>
2020/10/07
On Tue, Oct 6, 2020 at 7:25 PM NARUSE, Yui <naruse@airemix.jp> wrote:
[#100326] Re: How to use backport custom field
— "NARUSE, Yui" <naruse@...>
2020/10/07
I added you to "Reporter" role in the project
[#100327] Re: How to use backport custom field
— Jun Aruga <jaruga@...>
2020/10/07
On Wed, Oct 7, 2020 at 1:42 PM NARUSE, Yui <naruse@airemix.jp> wrote:
[#100358] [BUG] ruby 2.6.6 warning with encdb.so — shiftag <shiftag@...>
Hello,
1 message
2020/10/10
[ruby-core:100360] [Ruby master Bug#17259] Kernel#warn should ignore <internal: entries
From:
merch-redmine@...
Date:
2020-10-10 18:24:36 UTC
List:
ruby-core #100360
Issue #17259 has been updated by jeremyevans0 (Jeremy Evans). I agree with removing the Rubygems override of `Kernel#warn` (the only Kernel method Rubygems should override is `require`). Skipping `<internal:` entries for `uplevel` makes sense to me. ---------------------------------------- Bug #17259: Kernel#warn should ignore <internal: entries https://bugs.ruby-lang.org/issues/17259#change-87971 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Target version: 3.0 * ruby -v: ruby 3.0.0preview1 (2020-09-25 master 0096d2b895) [x86_64-linux] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- `Kernel#warn` currently does not skip `<internal:` entries from core library methods defined in Ruby. This can cause rather unhelpful locations to be used for warnings. For instance: ``` $ ruby -v --disable=gems -e 'def deprecated; warn "use X instead", uplevel: 1; end; tap(&:deprecated)' ruby 3.0.0preview1 (2020-09-25 master 0096d2b895) [x86_64-linux] <internal:kernel>:90: warning: use X instead # expected: "-e:1: warning: use X instead" ``` Note that RubyGems overrides Kernel#warn since https://github.com/rubygems/rubygems/pull/2442 and https://github.com/rubygems/rubygems/blob/c1bafab1d84e0aad06e377e9db4b74cccab4b43a/lib/rubygems/core_ext/kernel_warn.rb#L42, so `--disable-gems` is needed to observe this behavior. I think it is very suboptimal that RubyGems needs to monkey-patch Kernel#warn to remove RubyGems' `require` from `Kernel#warn` location. That is both fragile (as we've seen from various incompatible behavior and bugs in that monkey-patch) and inefficient (walking the stack multiple times). So I would suggest to actually skip all backtraces entries starting with `<internal:` for `Kernel#warn(message, uplevel:)`. BTW this is already what [TruffleRuby does](https://github.com/oracle/truffleruby/blob/c3bcccfd8db7d460e23f0371e7ceaf5fdb71275c/src/main/ruby/truffleruby/core/kernel.rb#L656). As a bonus, by filtering out `<internal:`, RubyGems could define its `require` in an `eval(code, nil, '<internal:rubygems-require>', line)` and it would automatically be skipped, without needing to monkey-patch Kernel#warn at all! -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>