[#118180] [Ruby master Bug#20525] Percent string literal with indentation support — "bradgessler (Brad Gessler) via ruby-core" <ruby-core@...>

Issue #20525 has been reported by bradgessler (Brad Gessler).

8 messages 2024/06/04

[#118243] [Ruby master Feature#20564] Switch default parser to Prism — "kddnewton (Kevin Newton) via ruby-core" <ruby-core@...>

Issue #20564 has been reported by kddnewton (Kevin Newton).

11 messages 2024/06/07

[#118269] [Ruby master Bug#20570] Nokey behavior changed since 3.3. — "ksss (Yuki Kurihara) via ruby-core" <ruby-core@...>

Issue #20570 has been reported by ksss (Yuki Kurihara).

8 messages 2024/06/10

[#118279] [Ruby master Bug#20573] Warning.warn shouldn't be called for disabled warnings — "tenderlovemaking (Aaron Patterson) via ruby-core" <ruby-core@...>

Issue #20573 has been reported by tenderlovemaking (Aaron Patterson).

10 messages 2024/06/10

[#118281] [Ruby master Misc#20574] DevMeeting-2024-07-11 — "mame (Yusuke Endoh) via ruby-core" <ruby-core@...>

Issue #20574 has been reported by mame (Yusuke Endoh).

12 messages 2024/06/11

[#118346] [Ruby master Bug#20586] Some filesystem calls in dir.c are missing error handling and can return incorrect results if interrupted — "ivoanjo (Ivo Anjo) via ruby-core" <ruby-core@...>

Issue #20586 has been reported by ivoanjo (Ivo Anjo).

13 messages 2024/06/19

[#118347] [Ruby master Bug#20587] dir.c calls blocking system calls while holding the GVL — "ivoanjo (Ivo Anjo) via ruby-core" <ruby-core@...>

Issue #20587 has been reported by ivoanjo (Ivo Anjo).

7 messages 2024/06/19

[#118360] [Ruby master Bug#20588] RangeError: integer 132186463059104 too big to convert to 'int' since cdf33ed5f37f9649c482c3ba1d245f0d80ac01ce with YJIT enabled — "yahonda (Yasuo Honda) via ruby-core" <ruby-core@...>

Issue #20588 has been reported by yahonda (Yasuo Honda).

10 messages 2024/06/20

[#118388] [Ruby master Feature#20594] A new String method to append bytes while preserving encoding — "byroot (Jean Boussier) via ruby-core" <ruby-core@...>

SXNzdWUgIzIwNTk0IGhhcyBiZWVuIHJlcG9ydGVkIGJ5IGJ5cm9vdCAoSmVhbiBCb3Vzc2llciku

32 messages 2024/06/25

[ruby-core:118291] [Ruby master Bug#20573] Warning.warn shouldn't be called for disabled warnings

From: "tenderlovemaking (Aaron Patterson) via ruby-core" <ruby-core@...>
Date: 2024-06-11 16:00:24 UTC
List: ruby-core #118291
Issue #20573 has been updated by tenderlovemaking (Aaron Patterson).


byroot (Jean Boussier) wrote in #note-6:
> In [Feature #16345] it was stated:
> 
> > We chose Warning.disable(:deprecated) instead of
> re-defining Warning.warn in order to avoid string object generation.
> 
> The intent was clearly for `Warning.warn` not to be called.

I'm reading the ticket the same way. It sounds like this is a bug.

----------------------------------------
Bug #20573: Warning.warn shouldn't be called for disabled warnings
https://bugs.ruby-lang.org/issues/20573#change-108795

* Author: tenderlovemaking (Aaron Patterson)
* Status: Open
* Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN
----------------------------------------
Currently `Warning.warn` will be called for all warnings, even if that particular category is disabled.

For example

```ruby
module Warning
  def warn(message, category:)
    p message => category
  end
end

def get_var
  $=
end

p Warning[:deprecated]
get_var
```

I think that internally we should _not_ call `Warning.warn` unless the category is enabled.

I've sent a PR here: https://github.com/ruby/ruby/pull/10960



-- 
https://bugs.ruby-lang.org/

In This Thread