Support passing a category to `Warning.warn`

This change adds a `category` kwarg to make it easier to monkey patch
`Warning.warn`. Warnings already have a category, but that warning isn't
exposed. This implements a way to get the category so that warnings with
a specific category, like deprecated, can be treated differently than
other warnings in an application.

The change here does an arity check on the method to support backwards
compatibility for applications that may already have a warning monkey
patch.

For our usecase we want to `raise` for deprecation warnings in order to
get the behavior for the next Ruby version. For example, now that we
fixed all our warnings and deployed Ruby 2.7 to production, we want to
be able to have deprecation warnings behave like they would in 3.0: raise
an error. For other warnings, like uninialized constants, that behavior
won't be removed from Ruby in the next version, so we don't need to
raise errors.

Co-authored-by: Aaron Patterson <tenderlove@ruby-lang.org>

1 files changed, 8 insertions, 0 deletions

diff --git a/NEWS.md b/NEWS.md
index 075c5ec8b9..1bc19e83e1 100644
--- a/NEWS.md
+++ b/NEWS.md
@@ -165,6 +165,13 @@ Outstanding ones only.
         * Symbol#to_proc now returns a lambda Proc.
           [[Feature #16260]]
 
+* Warning
+
+    * Modified method
+
+        * Warning#warn now supports a category kwarg.
+        [[Feature #17122]]
+
 ## Stdlib updates
 
 Outstanding ones only.
@@ -342,3 +349,4 @@ Excluding feature bug fixes.
 [Feature #16686]: https://bugs.ruby-lang.org/issues/16686
 [Misc #16961]:    https://bugs.ruby-lang.org/issues/16961
 [Bug #8446]:      https://bugs.ruby-lang.org/issues/8446
+[Feature #17122]: https://bugs.ruby-lang.org/issues/17122