[#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:100577] [Ruby master Feature#17143] Improve support for warning categories
From:
merch-redmine@...
Date:
2020-10-26 15:59:03 UTC
List:
ruby-core #100577
Issue #17143 has been updated by jeremyevans0 (Jeremy Evans). matz (Yukihiro Matsumoto) wrote in #note-10: > I am OK with warning categories. But the proposed categories are too fine-grained, I think. Here's the Python warning categories: > > https://docs.python.org/3/library/warnings.html#warning-categories Here are the Python 3 warning categories, along with the possible categories for Ruby: Warning: Base category in Python. I assume this would be a `nil` category in Ruby, and used for warnings that are not assigned a category? UserWarning: Should we use :user for this category and make Kernel#warn default to this category if a category isn't given? DeprecationWarning: We already have this category, :deprecated. SyntaxWarning: The :compile warning category in my original proposal covered this. Do we want to use :syntax instead? RuntimeWarning: This could potentially cover uninitialized instance/global variable access, method redefinition, ignored blocks, unknown argv flags, and many other things. Do we want to use a :runtime category for all of these? FutureWarning, PendingDeprecationWarning: Additional types of deprecation warnings in Python. Do we want to have multiple deprecation warning categories in Ruby? ImportWarning: The :require category in my original proposal covered this. UnicodeWarning, BytesWarning: This is related to unicode/bytes split in Python that Ruby does not have. The :encoding category in my original proposal is probably the closest similar thing in Ruby. ResourceWarning: The :range category in my original proposal is probably the closest similar thing in Ruby. The reason for using :uninitialized_ivar and :redefine fine grained categories is that they are probably the most useful to Rubyists. Most other warnings you would want to fix and make the warning go away, but there are valid performance reasons for not initializing instance variables, and valid thread-safety reasons for not undefining methods before redefining them. I'm happy to implement whatever warning categories are decided upon, after the decision has been made. ---------------------------------------- Feature #17143: Improve support for warning categories https://bugs.ruby-lang.org/issues/17143#change-88209 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal ---------------------------------------- Support was recently added for Warning.warn to accept a `category` keyword. However, the initial implementation was limited to having `rb_warn_deprecated` and `rb_warn_deprecated_to_remove` use the `:deprecated` value for the `category` keyword. It doesn't make sense to me to have a `category` keyword if it is only used for deprecation, so I propose we extend the support so that `Kernel#warn` accepts a category keyword (for Ruby-level warnings) and `rb_category_warn` and `rb_category_warning` functions be added to the C-API (for C-level warnings). I also propose that we change existing `rb_warn` and `rb_warning` calls to `rb_category_warn` and `rb_category_warning`, so that all warnings issued by core Ruby are issued with an appropriate category. I have implemented support for this in a pull request: https://github.com/ruby/ruby/pull/3508 -- 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>