- ruby-core - ml.ruby-lang.org

[ruby-core:112446] [Ruby master Bug#19442] Remove USE_RINCGC flag
by eightbitraptor (Matthew Valentine-House) 28 Dec '23

28 Dec '23

Issue #19442 has been reported by eightbitraptor (Matthew Valentine-House). ---------------------------------------- Bug #19442: Remove USE_RINCGC flag https://bugs.ruby-lang.org/issues/19442 * Author: eightbitraptor (Matthew Valentine-House) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- [GitHub PR #7317](https://github.com/ruby/ruby/pull/7313) Ruby doesn't compile when USE_RINCGC is disabled. It's also not being tested in CI. As @nobu has pointed out in comments on the PR, fixing it is simple. I think there are 2 approaches we could take: 1. Remove `USE_RINCGC` entirely and always run with incremental GC enabled. We have a precedent for this: `USE_RGENGC=0` was removed [in this commit](https://github.com/ruby/ruby/commit/62c2b8c74e47652fc5bbaf6150f4acd… almost 3 years ago. `USE_RINCGC=0` is in a similar state. It has been broken for almost a year (since [this commit](https://github.com/ruby/ruby/commit/dde164e968e382d50b07ad455946888…) and [disabled in CI for more than 2 years](https://github.com/ruby/ruby/commit/46d3ea2c2569e2e5a9ee3e7e206f07f0…. 2. We could fix `USE_RINCGC`. If we do this we should re-enable the CI task so that we continue to keep it working in the future. I am very much in favour of option 1, because I don't think this flag is being actively used, and removing it will simplify the code and reduce the cognitive overhead of working with the GC. However I am happy to defer to the team here. -- https://bugs.ruby-lang.org/

6 9

[ruby-core:115879] [Ruby master Bug#20081] Transfered Fiber doesn't return to Fiber that started it
by rmosolgo (Robert Mosolgo) 28 Dec '23

28 Dec '23

Issue #20081 has been reported by rmosolgo (Robert Mosolgo). ---------------------------------------- Bug #20081: Transfered Fiber doesn't return to Fiber that started it https://bugs.ruby-lang.org/issues/20081 * Author: rmosolgo (Robert Mosolgo) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-darwin22] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Hi! I'm trying to figure out how to make sure that Fibers started with `.transfer` end up _terminated_, not just suspended. (If they're suspended, Rails thinks they're still alive, and they continue to hold onto database connections, see: https://github.com/rmosolgo/graphql-ruby/issues/4739#issuecomment-1866930914.) So, I'm looking for way to make sure that any Fiber I start with `.transfer` will be properly terminated. But what I noticed is that when a transfer-based Fiber terminates, it gives control back to the top-most Fiber, not the Fiber which transfered to it. Is this intended? Here's a script to replicate the issue: ```ruby manager = Fiber.new do parent = Fiber.current worker = Fiber.new do puts "2. Begin Worker" parent.transfer puts "4. End Worker" end puts "1. Transfer 1" worker.transfer puts "3. Transfer 2" worker.transfer puts "5. Finished manager" end manager.transfer puts "6. Finished script" ``` I expect the steps to print in order: ``` 1. Transfer 1 2. Begin Worker 3. Transfer 2 4. End Worker 5. Finished manager 6. Finished script ``` But instead, `5. ...` is skipped: ``` 1. Transfer 1 2. Begin Worker 3. Transfer 2 4. End Worker 6. Finished script ``` I think that's because my `worker` fiber terminates and passes control back to the top-level Fiber. Should it have passed control back to the `manager`? Or is there another way to make sure `worker` is terminated, and `manager` gets control? -- https://bugs.ruby-lang.org/

2 4

[ruby-core:115938] [Ruby master Feature#20100] [Feature] Better / easier support for (optional) colours, on the commandline, in case a parsing error happened?
by rubyFeedback (robert heiler) 27 Dec '23

27 Dec '23

Issue #20100 has been reported by rubyFeedback (robert heiler). ---------------------------------------- Feature #20100: [Feature] Better / easier support for (optional) colours, on the commandline, in case a parsing error happened? https://bugs.ruby-lang.org/issues/20100 * Author: rubyFeedback (robert heiler) * Status: Open * Priority: Normal ---------------------------------------- This suggestion is primarily in regard to (optional) colour support, on the commandline, in case a parsing error happened. I'll explain what I mean with this in a moment. Let me first show a partial screenshot (image), to indicate this problem. https://i.imgur.com/FylLvsY.png Ruby evaluates the content and indicates the error here, while also helpfully showing the line numbers WHERE the error happened (on the left hand side). This is nice. But, I would actually prefer if some colours could be shown here, at the user's discretion. For instance, I would like to have the line numbers show in red or a red-colour; or any colour for that matter. That would give me a visual cue as to the primary problem (sometimes more than one error is shown, or occurs, in a given .rb file, or distributed via several .rb files). The keyword or type-error, such as SyntaxError, should ideally also use another colour. I may also want to see the specific error in yet another colour, e. g. the part ", "unexpected 'end". The error here was that I copy/pasted some code (I am porting old code and checking it as I do right now) and left behind a trailing ',' there. Hopefully I could convince the dear reader that colours may be important. Perhaps colour support is already possible, and I (and perhaps others) just don't know about it. So the question, then, would be: how to enable simple colours to be shown? Well, a couple of ways would be possible. A simple one may be to put an environment variable, and document it clearly, such as RUBY_ENABLE_COLOURS or RUBY_COLOURS, and a value of 1 to indicate that we want to use colours. Or any other name, these are just suggestions; can be longer names, to indicate on-error situations such as RUBY_SHOW_COLOURED_ERRORS or RUBY_COLOURED_ERRORS (or COLORED, I don't mind the UK or US spelling, even though I got used to the UK spelling due to UK being close to central Europe). There could also be an internal API we could call; not sure which one, perhaps via RbConfig, e. g. RbConfig.enable_colours or RbConfig::COLOURS_ON_WARNING = true or something like that. Or another way where this may reside, although an ENV variable may be simpler. A few other options may also be possible - either way the primary objective would be to make it super-easy and super-simple to have colours support, perhaps even for all of ruby, without needing to micro-manage ENV variables. Ideally https://docs.ruby-lang.org/en/ should also get a dedicate page about colours in general. On Windows colours may not always work well (I have had different success there) but on linux, bash, KDE konsole and so forth, colours work really well for me. At any rate this was the suggestion - thank you for reading this. PS: I searched for "colo" on the docs.ruby-lang.org webpage; results often involved e. g. IRB like https://docs.ruby-lang.org/en/3.3/IRB/Color.html, which is useful if someone wants to modify IRB's behaviour, but not so useful when it comes to general things concerning MRI. There is really a distinct lack of top-down overview-articles in regards to ruby on the official homepage. How are new users supposed to find things like that? It would be nice if a long-term strategy for ruby would also be to provide higher "overarching" documentation for ruby, via a central place (MRI). At any rate, this is a separate issue - my feature request here is concerning about enabling colours support on the commandline, in case of an error. The ruby parser probably already has this information, since it can show where an error happens, so all that may be necessary would be to tie this towards colour-output; and then also a way for people to tap into that (which is why I think an ENV variable, even though not super-sophisticated, may be the simplest way to go, but that should also be clearly documented in a very-easy-to-find, and accessible, manner). -- https://bugs.ruby-lang.org/

2 1

[ruby-core:115889] [Ruby master Bug#20084] Breaking change with Regexp.new on 3.3.0
by paddor (Patrik Wenger) 27 Dec '23

27 Dec '23

Issue #20084 has been reported by paddor (Patrik Wenger). ---------------------------------------- Bug #20084: Breaking change with Regexp.new on 3.3.0 https://bugs.ruby-lang.org/issues/20084 * Author: paddor (Patrik Wenger) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Regexp.new used to take up to 3 arguments, but now only 1..2 are allowed: ``` [1] pry(main)> Regexp.new 'abc', 'i', 'n' ArgumentError: wrong number of arguments (given 3, expected 1..2) from (pry):1:in `initialize' ``` On 3.2.2: ``` [1] pry(main)> Regexp.new 'abc', 'i', 'n' => /abc/in ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:115918] [Ruby master Bug#20092] Warnings for anonymous parameters do not display in Ruby 3.4dev
by koic (Koichi ITO) 27 Dec '23

27 Dec '23

Issue #20092 has been reported by koic (Koichi ITO). ---------------------------------------- Bug #20092: Warnings for anonymous parameters do not display in Ruby 3.4dev https://bugs.ruby-lang.org/issues/20092 * Author: koic (Koichi ITO) * Status: Open * Priority: Normal * ruby -v: ruby 3.4.0dev (2023-12-26T22:32:38Z master be92bf4ff4) [x86_64-darwin22] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I encountered no expected warnings in Ruby 3.4dev. ## Reproduction code ```ruby def anonymous(*, **, &) rest_block do foo(*) end kwrest_block do bar(**) end block_block do baz(&) end end ``` ## Expected Behavior (Ruby 3.3.0) Warnings are displayed: ```ruby $ ruby -vc example.rb ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-darwin22] example.rb: example.rb:3: anonymous rest parameter is also used within block (SyntaxError) example.rb:7: anonymous keyword rest parameter is also used within block example.rb:11: anonymous block parameter is also used within block ``` ## Actual Behavior (Ruby 3.4dev) No warning displayed: ```ruby $ ruby -vc example.rb ruby 3.4.0dev (2023-12-26T22:32:38Z master be92bf4ff4) [x86_64-darwin22] Syntax OK ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:115208] [Ruby master Feature#19982] Bump required Visual Studio version to 2015 after 3.3
by kddnewton (Kevin Newton) 27 Dec '23

27 Dec '23

Issue #19982 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Feature #19982: Bump required Visual Studio version to 2015 after 3.3 https://bugs.ruby-lang.org/issues/19982 * Author: kddnewton (Kevin Newton) * Status: Open * Priority: Normal ---------------------------------------- Visual Studio 2013 is finally being EOL'd next April. (https://learn.microsoft.com/en-us/visualstudio/productinfo/vs-servicing#old…) Let's drop support for it after Ruby 3.3 is released. If we bump the required version to Visual Studio 2015, we'll get better C99 support and be able to rely on some more standards. Personally I'm excited about `snprintf` being actually implemented. (https://learn.microsoft.com/en-us/cpp/overview/visual-cpp-language-conforma…) As support for the argument, CPython requires VS2017 (https://github.com/python/cpython/blob/main/PCbuild/readme.txt) and gnulib requires VS2015(https://www.gnu.org/software/gnulib/manual/html_node/Supported-Platf…. -- https://bugs.ruby-lang.org/

5 5

[ruby-core:115565] [Ruby master Feature#20034] [mkmf] Support creating a compilation database for C language tooling
by pounce (Calvin Lee) 27 Dec '23

27 Dec '23

Issue #20034 has been reported by pounce (Calvin Lee). ---------------------------------------- Feature #20034: [mkmf] Support creating a compilation database for C language tooling https://bugs.ruby-lang.org/issues/20034 * Author: pounce (Calvin Lee) * Status: Open * Priority: Normal ---------------------------------------- # Abstract Ruby projects are often developed with C extensions. These can be easily compiled by ruby by using `create_makefile` in `mkmf.rb`. Unfortunately, most C tooling is unable to interpret the ruby build system for C files, and thus cannot provide useful diagnostics to users about their C extensions. This request entails generating a compilation database (as discussed below), which would allow C tooling to understand how the extensions are compiled. # Background A [compilation database](https://clang.llvm.org/docs/JSONCompilationDatabase.html) is a standard format used to describe how C and C++ translation units are compiled. This is primarily used for a build system to communicate to C language tooling (such as a language server). Language servers need this information in order to determine how symbols, definitions and declarations are related in different files; and allows them to show descriptive warnings that may occur during compilation. This also allows users to perform quick and efficient refactors in their text editor. It is supported by many build systems by default, such as CMake and Meson. These build systems often place a `compile_commands.json` in the `build/` directory, which is automatically detected by most language servers. It is also supported by language servers such as clangd and ccls. # Proposal When generating a makefile in `create_makefile`, a compilation database should also be created for all targets that are to be compiled. # Implementation The location of the compilation database should be configurable, both by library and environment variable, so that a user may redirect the compilation database to a specific location if they desire. # Evaluation This feature should be evaluated as successful if it is compatible with common language servers such as clangd and ccls. For example, if a user first compiles a project and then edits a C file that is compiled, then clangd should work with little to no configuration. # Discussion For more information about compilation databases, please see [clangd's informational site](https://clangd.llvm.org/design/compile-commands) as well as [the ccls wiki])(https://github.com/MaskRay/ccls/wiki/Project-Setup) There is also an [article](https://sarcasm.github.io/notes/dev/compilation-database.html) by [Guillaume Papin](https://github.com/sarcasm) which discusses compilation databases and software which supports them. As an alternative, users may use [Bear](https://github.com/rizsotto/Bear) to generate their compilation database. However, this is not optimal, as it only works on Linux. Furthermore, Bear is only able to capture flags for C files which are compiled during a single execution of the build system. Thus, is not able to record flags for C files which have been skipped. -- https://bugs.ruby-lang.org/

4 6

[ruby-core:115913] [Ruby master Bug#20091] Anonymous block method parameters no longer usable within blocks with ruby 3.3
by sigsys (Math Ieu) 27 Dec '23

27 Dec '23

Issue #20091 has been reported by sigsys (Math Ieu). ---------------------------------------- Bug #20091: Anonymous block method parameters no longer usable within blocks with ruby 3.3 https://bugs.ruby-lang.org/issues/20091 * Author: sigsys (Math Ieu) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [amd64-freebsd13] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- This used to work on 3.1 and 3.2, but now fails with "anonymous block parameter is also used within block (SyntaxError)": ``` def g = yield def f(&) g { g(&) } end p f { 123 } ``` And something like this also fails: ``` def f(&) loop do return g(&) end end ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115908] [Ruby master Bug#18805] IO::Buffer is inconsistent when returning a string from an empty buffer
by ioquatix (Samuel Williams) 26 Dec '23

26 Dec '23

Issue #18805 has been updated by ioquatix (Samuel Williams). This is currently working as intended but we could consider changing the behaviour. I understand the use case. ---------------------------------------- Bug #18805: IO::Buffer is inconsistent when returning a string from an empty buffer https://bugs.ruby-lang.org/issues/18805#change-105866 * Author: procmarco (Marco Concetto Rudilosso) * Status: Open * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- I’ve been using `IO::Buffer` and I found it to be slightly inconsistent when it comes to returning empty string for empty buffers. for example, a slice of an allocated buffer with `size = 0`, returns `""` with `get_string`, as an example: ```ruby buffer = IO::Buffer.new(5) empty_buffer = buffer.slice(0,0) puts empty_buffer.size # this prints 0 empty_buffer.get_string # this returns "" ``` but, if you create a buffer with IO::Buffer.new(0) then it stops working ```ruby empty_buffer = IO::Buffer.new(0) puts empty_buffer.size # this prints 0 empty_buffer.get_string # this raises The buffer is not allocated! (IO::Buffer::AllocationError) ``` Is this working as intended? It would be good I think to have a consistent experience where the base case (buffer with size 0) always returns an empty string. I have a prototype of a possible patch I could send upstream to fix it, which would check the size of the buffer and if 0 it would always return an empty string. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113951] [Ruby master Bug#19738] `ObjectSpace.each_object.to_a` crashes in `make runirb`.
by ioquatix (Samuel Williams) 26 Dec '23

26 Dec '23

Issue #19738 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #19738: `ObjectSpace.each_object.to_a` crashes in `make runirb`. https://bugs.ruby-lang.org/issues/19738 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ``` > make runirb RUBY_ON_BUG='gdb -x ./.gdbinit -p' ./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems -r irb -e 'IRB.start("make runirb")' irb(main):001:0> ObjectSpace.each_object.to_a Assertion Failed: ./vm_method.c:1366:callable_method_entry_or_negative:RB_TYPE_P(klass, T_CLASS) || RB_TYPE_P(klass, T_ICLASS) ruby 3.3.0dev (2023-06-19T19:19:45Z master 9ff4399dec) [arm64-darwin22] ``` I have no idea why. ---Files-------------------------------- error.txt (12.9 KB) -- https://bugs.ruby-lang.org/

2 3