November 2024 - ruby-core - ml.ruby-lang.org

[ruby-core:119513] [Ruby master Bug#20795] Timeout method doesn't check for negative time values
by kanakchaudhari12 (kanak chaudhari) 03 Dec '24

03 Dec '24

Issue #20795 has been reported by kanakchaudhari12 (kanak chaudhari). ---------------------------------------- Bug #20795: Timeout method doesn't check for negative time values https://bugs.ruby-lang.org/issues/20795 * Author: kanakchaudhari12 (kanak chaudhari) * Status: Open * ruby -v: 3.1.0 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ```ruby require 'timeout' # Case 1: Negative timeout with quick execution Timeout.timeout(-5) do puts "This should not execute" end # Case 2: Negative timeout with sleep Timeout.timeout(-5) do sleep(10) end ``` Potential issues with current behaviour: * Inconsistency: The behaviour differs based on the block's content, which may not be immediately apparent * Silent failure: The negative timeout is silently ignored, potentially masking logical errors in the calling code. * Unexpected source of error: one might expect the timeout method to validate its input, rather than relying on methods called within the block to catch invalid time values. I suggest this change for the consistent behaviour regardless of code-block as well as the clear indication of the source of the error ```ruby def timeout(sec, klass = nil, message = nil, &block) raise ArgumentError, "timeout must be positive" if sec.is_a?(Numeric) && sec < 0 # ... end ``` -- https://bugs.ruby-lang.org/

4 4

[ruby-core:120033] [Ruby master Bug#20916] Prism compiler should support ** in Ractor constant
by mame (Yusuke Endoh) 02 Dec '24

02 Dec '24

Issue #20916 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #20916: Prism compiler should support ** in Ractor constant https://bugs.ruby-lang.org/issues/20916 * Author: mame (Yusuke Endoh) * Status: Open * Assignee: prism * ruby -v: ruby 3.4.0dev (2024-11-28T02:34:20Z avoid-uninitialize.. 79ae6e72c8) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- The Prism compiler raises an exception against the following code. ``` $ ./miniruby -e '# shareable_constant_value: experimental_everything C = { **{ } }' -e:2: Ractor constant writes do not support ** -e: node type not implemented (NotImplementedError) ``` But the traditional compiler support it, and @ko1 said it should be supported. Also, I feel that this error message `node type not implemented` is a sign of a worse problem. Actually, valgrind reports `Conditional jump or move depends on uninitialised value(s)`against the Prism compiler. An assertion failure is also reported. ``` $ valgrind ./miniruby -e '# shareable_constant_value: experimental_everything C = { **{ } }' ==49978== Memcheck, a memory error detector ==49978== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==49978== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info ==49978== Command: ./miniruby -e #\ shareable_constant_value:\ experimental_everything_C\ =\ {\ **{\ }\ } ==49978== ==49978== Warning: set address range perms: large range [0x64e0000, 0x1e4e0000) (defined) -e:2: Ractor constant writes do not support ** ==49978== Conditional jump or move depends on uninitialised value(s) ==49978== at 0x4BB42A: pm_newline_list_line (pm_newline_list.c:63) ==49978== by 0x1E718A: pm_compile_shareable_constant_value (prism_compile.c:5280) ==49978== by 0x1E7243: pm_compile_shareable_constant_value (prism_compile.c:5318) ==49978== by 0x1E8DC1: pm_compile_constant_write_node.isra.0 (prism_compile.c:5372) ==49978== by 0x1DCB2F: pm_compile_node (prism_compile.c:9823) ==49978== by 0x1DC9C8: pm_compile_node (prism_compile.c:9934) ==49978== by 0x1F3AC9: pm_compile_scope_node.isra.0 (prism_compile.c:6603) ==49978== by 0x1DA66A: pm_compile_node (prism_compile.c:9805) ==49978== by 0x1F61A7: pm_iseq_compile_node (prism_compile.c:10109) ==49978== by 0x2A5303: pm_iseq_new_with_opt_try (iseq.c:1027) ==49978== by 0x23DFF2: rb_protect (eval.c:1033) ==49978== by 0x2AB198: pm_iseq_new_with_opt (iseq.c:1080) ==49978== miniruby: prism/util/pm_newline_list.c:63: pm_newline_list_line: Assertion `cursor >= list->start' failed. ==49978== ==49978== Process terminating with default action of signal 6 (SIGABRT) ==49978== at 0x4AFAB1C: __pthread_kill_implementation (pthread_kill.c:44) ==49978== by 0x4AFAB1C: __pthread_kill_internal (pthread_kill.c:78) ==49978== by 0x4AFAB1C: pthread_kill@@GLIBC_2.34 (pthread_kill.c:89) ==49978== by 0x4AA126D: raise (raise.c:26) ==49978== by 0x4A848FE: abort (abort.c:79) ==49978== by 0x4A8481A: __assert_fail_base.cold (assert.c:94) ==49978== by 0x4A97506: __assert_fail (assert.c:103) ==49978== by 0x4BB49B: pm_newline_list_line (pm_newline_list.c:63) ==49978== by 0x1E718A: pm_compile_shareable_constant_value (prism_compile.c:5280) ==49978== by 0x1E7243: pm_compile_shareable_constant_value (prism_compile.c:5318) ==49978== by 0x1E8DC1: pm_compile_constant_write_node.isra.0 (prism_compile.c:5372) ==49978== by 0x1DCB2F: pm_compile_node (prism_compile.c:9823) ==49978== by 0x1DC9C8: pm_compile_node (prism_compile.c:9934) ==49978== by 0x1F3AC9: pm_compile_scope_node.isra.0 (prism_compile.c:6603) ==49978== ==49978== HEAP SUMMARY: ==49978== in use at exit: 2,645,494 bytes in 10,084 blocks ==49978== total heap usage: 36,662 allocs, 26,578 frees, 6,066,537 bytes allocated ==49978== ==49978== LEAK SUMMARY: ==49978== definitely lost: 0 bytes in 0 blocks ==49978== indirectly lost: 0 bytes in 0 blocks ==49978== possibly lost: 1,050,576 bytes in 4 blocks ==49978== still reachable: 1,594,918 bytes in 10,080 blocks ==49978== suppressed: 0 bytes in 0 blocks ==49978== Rerun with --leak-check=full to see details of leaked memory ==49978== ==49978== Use --track-origins=yes to see where uninitialised values come from ==49978== For lists of detected and suppressed errors, rerun with: -s ==49978== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Aborted (core dumped) ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:120002] [Ruby master Bug#20908] Ruby extension builds fail with GCC 15 which defaults to -std=gnu23
by thesamesam (Sam James) 01 Dec '24

01 Dec '24

Issue #20908 has been reported by thesamesam (Sam James). ---------------------------------------- Bug #20908: Ruby extension builds fail with GCC 15 which defaults to -std=gnu23 https://bugs.ruby-lang.org/issues/20908 * Author: thesamesam (Sam James) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Hi! Upcoming GCC 15 defaults to C23 (`-std=gnu23`). One thing C23 changes is removing unprototyped functions, so `void foo()` now means `void foo(void)`, rather than "any arguments". Ruby extensions fail to build as a result with GCC 15. This was reported downstream in Gentoo at https://bugs.gentoo.org/943784 where brotli-0.6.0 is an example: ``` make: Entering directory '/var/tmp/portage/dev-ruby/brotli-0.6.0/work/ruby32/brotli-0.6.0/ext/brotli' x86_64-pc-linux-gnu-gcc -I. -I/usr/include/ruby-3.2.0/x86_64-linux -I/usr/include/ruby-3.2.0/ruby/backward -I/usr/include/ruby-3.2.0 -I. -DHAVE_BROTLI_DECODE_H -DHAVE_BROTLI_ENCODE_H -fPIC -O2 -pipe -march=native -fno-diagnostics-color -o brotli.o -c brotli.c In file included from /usr/include/ruby-3.2.0/ruby/ruby.h:27, from /usr/include/ruby-3.2.0/ruby.h:38, from brotli.h:4, from brotli.c:1: brotli.c: In function ‘Init_brotli’: /usr/include/ruby-3.2.0/ruby/internal/anyargs.h:363:45: error: passing argument 3 of ‘rb_define_singleton_method_m1’ from incompatible pointer type [-Wincompatible-pointer-types] 363 | # define RUBY_METHOD_FUNC(func) RBIMPL_CAST((VALUE (*)(ANYARGS))(func)) | ^ | | | VALUE (*)(void) {aka long unsigned int (*)(void)} /usr/include/ruby-3.2.0/ruby/internal/anyargs.h:308:144: note: in definition of macro ‘rb_define_singleton_method’ 308 | #define rb_define_singleton_method(obj, mid, func, arity) RBIMPL_ANYARGS_DISPATCH_rb_define_singleton_method((arity), (func))((obj), (mid), (func), (arity)) | ^~~~ /usr/include/ruby-3.2.0/ruby/internal/anyargs.h:363:33: note: in expansion of macro ‘RBIMPL_CAST’ 363 | # define RUBY_METHOD_FUNC(func) RBIMPL_CAST((VALUE (*)(ANYARGS))(func)) | ^~~~~~~~~~~ brotli.c:478:55: note: in expansion of macro ‘RUBY_METHOD_FUNC’ 478 | rb_define_singleton_method(rb_mBrotli, "deflate", RUBY_METHOD_FUNC(brotli_deflate), -1); | ^~~~~~~~~~~~~~~~ /usr/include/ruby-3.2.0/ruby/internal/anyargs.h:271:21: note: expected ‘VALUE (*)(int, union <anonymous>, VALUE)’ {aka ‘long unsigned int (*)(int, union <anonymous>, long unsigned int)’} but argument is of type ‘VALUE (*)(void)’ {aka ‘long unsigned int (*)(void)’} 271 | RBIMPL_ANYARGS_DECL(rb_define_singleton_method, VALUE, const char *) | ^~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/include/ruby-3.2.0/ruby/internal/anyargs.h:254:41: note: in definition of macro ‘RBIMPL_ANYARGS_DECL’ 254 | RBIMPL_ANYARGS_ATTRSET(sym) static void sym ## _m1(__VA_ARGS__, VALUE(*)(int, union { VALUE *x; const VALUE *y; } __attribute__((__transparent_union__)), VALUE), int); \ | ^~~ ``` The `ANYARGS` macro can't work in its current form, as defined at e.g. https://github.com/ruby/ruby/blob/f127bcb8294fd417c253dd7acab3ff3b9f0bf555/…: ``` #ifndef ANYARGS # ifdef __cplusplus # define ANYARGS ... # else # define ANYARGS # endif #endif ``` ... because of the change in C23 I mentioned above, i.e. `(ANYARGS)` being `()` now means no arguments, not any. I note that Ruby was adapted in part already for this change, see e.g. https://github.com/ruby/ruby/commit/4e64edb6cd8d1b444c591bfd50ec3d357e794f6e, but it appears that the headers that extensions need to build against aren't yet ready. -- https://bugs.ruby-lang.org/

4 6

[ruby-core:119942] [Ruby master Bug#20898] Backport https://github.com/ruby/ruby/pull/9737 to Ruby 3.3 and 3.2
by katei (Yuta Saito) 30 Nov '24

30 Nov '24

Issue #20898 has been reported by katei (Yuta Saito). ---------------------------------------- Bug #20898: Backport https://github.com/ruby/ruby/pull/9737 to Ruby 3.3 and 3.2 https://bugs.ruby-lang.org/issues/20898 * Author: katei (Yuta Saito) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- The memory corruption issue on Wasm led to mysterious crashes and [consumed much debugging time](https://github.com/ruby/ruby.wasm/issues/555). It's nice to backport the fix to save developers time. https://github.com/ruby/ruby/pull/9737 -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120016] [Ruby master Feature#20912] Move warning when redefining object_id to __id__
by jhawthorn (John Hawthorn) 29 Nov '24

29 Nov '24

Issue #20912 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Feature #20912: Move warning when redefining object_id to __id__ https://bugs.ruby-lang.org/issues/20912 * Author: jhawthorn (John Hawthorn) * Status: Open ---------------------------------------- Currently if you create a class and redefine or remove either `object_id` or `__send__` it will issue a warning. There's no such warning on `__id__`. ``` ❯ ruby -we 'class << Object.new; def object_id = 1; end' -e:1: warning: redefining `object_id' may cause serious problems ❯ ruby -we 'class << Object.new; def __id__ = 1; end' ❯ ``` It makes sense that there's no warning on `send`, because we expect `__send__` to be the method reliably available. `__send__` is on `BasicObject`, `send` is only on `Kernel`. This seems a little inconsistent that `object_id` warns while `__id__` does not warn. `__id__` is the equivalent to `__send__` as it's also on `BasicObject`, where `object_id` is only on `Kernel`. This may be a more obvious problem in Ruby 3.4.0 as commit:cffd380390967d17899fde0a81f5151ae6ddd076 makes the warning print in more cases. I propose we change this warning to be emitted only when `__id__` is redefined and not when `object_id` is redefined: **Proposed behaviour:** ``` ❯ ruby -we 'class << Object.new; def object_id = 1; end' ❯ ruby -we 'class << Object.new; def __id__ = 1; end' -e:1: warning: redefining `__id__' may cause serious problems ❯ ``` -- https://bugs.ruby-lang.org/

6 10

[ruby-core:120055] [Ruby master Misc#20923] Add builds for existing shared GC's to CI
by eightbitraptor (Matt V-H) 29 Nov '24

29 Nov '24

Issue #20923 has been reported by eightbitraptor (Matt V-H). ---------------------------------------- Misc #20923: Add builds for existing shared GC's to CI https://bugs.ruby-lang.org/issues/20923 * Author: eightbitraptor (Matt V-H) * Status: Open ---------------------------------------- ## Summary I'd like to add CI builds that exercise the GC API implementation with the currently supported known GC modules. Implemented in [[GH-#12212]](https://github.com/ruby/ruby/pull/12212) ## Background Ruby now ships with a GC API, through which GC implementations communicate with the VM. By default the existing Ruby GC is compiled into the released binaries as it always has been. Optionally, the Ruby GC can be compiled as a shared object and loaded through the API. Ruby also provides a second GC implementation based on MMTk that can also be built as a module and loaded through the API. The MMTk implementation is being developed in the `ruby/mmtk` repository and synced into `ruby/ruby` using the existing gem syncing mechanisms. Currently the Ruby CI exercises that it can build the default GC as a shared object, but it doesn't exercise whether it can load a shared GC correctly. ## Implementation The attached ticket provides Github Actions workflows that: - build Ruby with shared GC support - build both provided GC's as shared objects - run `make check` with both modular GC libraries It's important to note that this CI workflow will only test code that is directly included in the `ruby/ruby` repository. MMTk development work will be happening inside `ruby/mmtk` so these changes will be fully tested there. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:118003] [Ruby master Bug#20506] Failure compiling Ruby 3.4.0-preview1 on aarch64 on a mac and linux (Ubuntu 24.04)
by schneems (Richard Schneeman) 29 Nov '24

29 Nov '24

Issue #20506 has been reported by schneems (Richard Schneeman). ---------------------------------------- Bug #20506: Failure compiling Ruby 3.4.0-preview1 on aarch64 on a mac and linux (Ubuntu 24.04) https://bugs.ruby-lang.org/issues/20506 * Author: schneems (Richard Schneeman) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I was unable to compile Ruby 3.4.0-preview1 on Ubuntu 24.04 via Github Actions. As the logs are not retained indefinitely here's a link to the compilation failure: https://gist.github.com/schneems/bc6bdd6fba08ff6bfdd1bce8d76c457d The relevant errors seem to be in linking yjit: ``` touch yjit/target/release/libyjit.a partial linking yjit/target/release/libyjit.a into yjit/target/release/libyjit.o linking miniruby /usr/bin/ld: yjit/target/release/libyjit.o: in function `__multc3': /cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.108/./lib/builtins/multc3.c:33:(.text.__multc3+0x30c): undefined reference to `__builtin_copysignq' /usr/bin/ld: /cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.108/./lib/builtins/multc3.c:34:(.text.__multc3+0x394): undefined reference to `__builtin_copysignq' /usr/bin/ld: /cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.108/./lib/builtins/multc3.c:42:(.text.__multc3+0x7f4): undefined reference to `__builtin_copysignq' /usr/bin/ld: /cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.108/./lib/builtins/multc3.c:43:(.text.__multc3+0x864): undefined reference to `__builtin_copysignq' /usr/bin/ld: /cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.108/./lib/builtins/multc3.c:47:(.text.__multc3+0x8c4): undefined reference to `__builtin_copysignq' /usr/bin/ld: yjit/target/release/libyjit.o:/cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.108/./lib/builtins/multc3.c:38: more undefined references to `__builtin_copysignq' follow collect2: error: ld returned 1 exit status make: *** [Makefile:298: miniruby] Error 1 /tmp/lib/build_script.rb:118:in `pipe': Command failed debugflags="-g" ./configure --disable-install-doc --prefix /tmp/d20240524-1-bdq0bj/prefix --enable-load-relative --enable-shared --enable-yjit && make -j16 && make install (RuntimeError) from /tmp/lib/build_script.rb:158:in `block in build' from /tmp/lib/build_script.rb:152:in `chdir' from /tmp/lib/build_script.rb:152:in `build' from /tmp/lib/build_script.rb:65:in `block in run_build_script' from /usr/lib/ruby/3.2.0/tmpdir.rb:94:in `mktmpdir' from /tmp/lib/build_script.rb:61:in `run_build_script' from /tmp/build.rb:8:in `<main>' ``` Here's the GHA link: https://github.com/heroku/docker-heroku-ruby-builder/actions/runs/922553814…. This is the Dockerfile for Ubuntu 24.04 https://github.com/heroku/docker-heroku-ruby-builder/blob/73bdda974811717ba…. I'm able to reproduce the failure locally: ``` $ git clone https://github.com/heroku/docker-heroku-ruby-builder $ cd docker-heroku-ruby-builder $ export DOCKER_DEFAULT_PLATFORM=linux/arm64 $ bin/activate_docker heroku-24 $ bin/build_ruby heroku-24 3.4.0-preview1 # Fails ``` Full output https://gist.github.com/schneems/cfa21847228d48e6bbe27463deae6745. I'm also seeing failures when using `ruby-install` on my mac (ARM), the error message is different so I'm not sure if it's the same problem or unrelated: https://gist.github.com/schneems/12af87e967126c7bfa319645b00015b3 -- https://bugs.ruby-lang.org/

6 11

[ruby-core:116760] [Ruby master Feature#20265] Deprecate and remove rb_newobj and rb_newobj_of
by peterzhu2118 (Peter Zhu) 28 Nov '24

28 Nov '24

Issue #20265 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Feature #20265: Deprecate and remove rb_newobj and rb_newobj_of https://bugs.ruby-lang.org/issues/20265 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Priority: Normal ---------------------------------------- GitHub PR: https://github.com/ruby/ruby/pull/9964 I’m proposing deprecating and removing the rb_newobj and rb_newobj_of APIs because they are difficult to use, fragile to use, and requires knowledge of the internal implementation of data types in Ruby. The rb_newobj function creates a T_NONE object. T_NONE objects are tricky to deal with since T_NONE objects cannot be marked, T_NONE objects are not reclaimed by the GC, and changing the object to other types require internal knowledge about the data type. T_NONE objects are not allowed to be marked, so it cannot be GC managed. Since T_NONE objects are skipped during sweeping, it will leak Ruby heap memory if the developer never changes the object to another type. Changing a T_NONE object to another type is tricky. For example, T_STRING objects have many flags for embedded, shared, shared root, encoding, coderange, etc. Many of these flags are not public, preventing direct use by developers. Developers must understand these flags to convert a T_NONE object into a T_STRING object. While the rb_newobj_of function is easier to use than the rb_newobj function, it still requires developers to understand flags, meaning some issues of rb_newobj also apply to rb_newobj_of. Below is the usage of RB_NEWOBJ, rb_newobj, rb_newobj_of, RB_NEWOBJ_OF with vendored Ruby and comments removed. You can see that there are very few gems using these APIs and all are from over a decade ago (the most recent one is from 2011). ``` 2009-11-18 /srv/gems/bleak_house-7.2/ruby/ruby-1.8.7.patch:@@ -438,10 +438,8 @@ rb_newobj() 2023-07-01 /srv/gems/daqing_rucaptcha-3.2.2/ext/rucaptcha/target/release/build/rb-sys-6bdd5b2895b9570a/out/bindings-0.9.78-arm64-darwin22-3.2.2.rs: pub fn rb_newobj() -> VALUE; 2023-07-01 /srv/gems/daqing_rucaptcha-3.2.2/ext/rucaptcha/target/release/build/rb-sys-6bdd5b2895b9570a/out/bindings-0.9.78-arm64-darwin22-3.2.2.rs: pub fn rb_newobj_of(klass: VALUE, flags: VALUE) -> VALUE; 2010-08-06 /srv/gems/langscan-1.2/ext/langscan/ruby/compat/ripper/ripper.c: NODE *n = (NODE*)rb_newobj(); 2011-02-03 /srv/gems/memprof-0.3.10/ext/memprof.c: VALUE ret = rb_newobj(); 2011-02-03 /srv/gems/memprof-0.3.10/ext/tracers/objects.c: last_obj = orig_rb_newobj(); 2006-02-28 /srv/gems/refe-0.8.0.3/data/refe/function_source/rb/newobj:rb_newobj() 2006-02-28 /srv/gems/refe-0.8.0.3/data/refe/function_source/rb/node/newnode: NODE *n = (NODE*)rb_newobj(); 2011-08-31 /srv/gems/ruby-rpm-1.3.1/ext/rpm/dependency.c: prov = rb_newobj(); 2011-08-31 /srv/gems/ruby-rpm-1.3.1/ext/rpm/dependency.c: req = rb_newobj(); 2011-08-31 /srv/gems/ruby-rpm-1.3.1/ext/rpm/dependency.c: conf = rb_newobj(); 2011-08-31 /srv/gems/ruby-rpm-1.3.1/ext/rpm/dependency.c: obso = rb_newobj(); 2011-08-31 /srv/gems/ruby-rpm-1.3.1/ext/rpm/file.c: file = rb_newobj(); 2011-08-31 /srv/gems/ruby-rpm-1.3.1/ext/rpm/source.c: src = rb_newobj(); 2011-08-31 /srv/gems/ruby-rpm-1.3.1/ext/rpm/source.c: src = rb_newobj(); 2011-08-31 /srv/gems/ruby-rpm-1.3.1/ext/rpm/source.c: src = rb_newobj(); 2011-08-31 /srv/gems/ruby-rpm-1.3.1/ext/rpm/version.c: ver = rb_newobj(); 2011-08-31 /srv/gems/ruby-rpm-1.3.1/ext/rpm/version.c: ver = rb_newobj(); 2011-08-31 /srv/gems/ruby-rpm-1.3.1/ext/rpm/version.c: ver = rb_newobj(); 2006-11-30 /srv/gems/sydparse-1.2.0/sydparse.c: syd_scope = (struct SCOPE*)rb_newobj(); 2006-11-30 /srv/gems/sydparse-1.2.0/sydparse.y: syd_scope = (struct SCOPE*)rb_newobj(); ``` -- https://bugs.ruby-lang.org/

5 7

[ruby-core:120029] [Ruby master Feature#20914] Constructor Parameter Shortcuts
by artemb (Artem Borodkin) 28 Nov '24

28 Nov '24

Issue #20914 has been reported by artemb (Artem Borodkin). ---------------------------------------- Feature #20914: Constructor Parameter Shortcuts https://bugs.ruby-lang.org/issues/20914 * Author: artemb (Artem Borodkin) * Status: Open ---------------------------------------- # Constructor Parameter Shortcuts I propose adding a new syntax to simplify the constructor definition in the classes. Defining a constructor often involves repetitive assignments of parameters to instance variables. This pattern is verbose and can easily become cumbersome, especially in classes with many instance variables. The proposed syntax allows instance variables to be automatically assigned from constructor arguments, improving code clarity and brevity. **Basic Usage**: - **Current**: ```ruby class User def initialize(name, age, email = nil) @name = name @age = age @email = email end end ``` - **Proposed**: ```ruby class User def initialize(@name, @age, @email = nil) = end ``` **Named Parameters**: - **Current**: ```ruby class Product def initialize(name:, price:, description: 'No description available') @name = name @price = price @description = description end end product = Product.new(name: 'Laptop', price: 1000) ``` - **Proposed**: ```ruby class Product def initialize(@name:, @price:, @description: 'No description available') = end product = Product.new(name: 'Laptop', price: 1000) ``` **Mixing Named and Positional Parameters**: - **Current**: ```ruby class Booking def initialize(date, time, customer:, notes: '') @date = date @time = time @customer = customer @notes = notes end end booking = Booking.new('2023-04-01', '14:00', customer: 'Alice', notes: 'First-time client') ``` - **Proposed**: ```ruby class Booking def initialize(@date, @time, @customer:, @notes: '') = end booking = Booking.new('2023-04-01', '14:00', customer: 'Alice', notes: 'First-time client') ``` -- https://bugs.ruby-lang.org/

3 4

[ruby-core:119741] [Ruby master Bug#20869] IO buffer handling is inconsistent when seeking
by javanthropus (Jeremy Bopp) 28 Nov '24

28 Nov '24

Issue #20869 has been reported by javanthropus (Jeremy Bopp). ---------------------------------------- Bug #20869: IO buffer handling is inconsistent when seeking https://bugs.ruby-lang.org/issues/20869 * Author: javanthropus (Jeremy Bopp) * Status: Open * ruby -v: ruby 3.3.4 (2024-07-09 revision be1089c8ec) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- When performing any of the seek based operations on IO (IO#seek, IO#pos=, or IO#rewind), the read buffer is inconsistently cleared: ```ruby require 'tempfile' Tempfile.open do |f| f.write('0123456789') f.rewind # Calling #ungetbyte as the first read buffer # operation uses a buffer that is preserved during # seek operations f.ungetbyte(97) # Byte buffer will not be cleared f.seek(2, :SET) f.getbyte # => 97 end Tempfile.open do |f| f.write('0123456789') f.rewind # Calling #getbyte before #ungetbyte uses a # buffer that is not preserved when seeking f.getbyte f.ungetbyte(97) # Byte buffer will be cleared f.seek(2, :SET) f.getbyte # => 50 end ``` Similar behavior happens when reading characters: ```ruby require 'tempfile' Tempfile.open do |f| f.write('0123456789') f.rewind # Calling #ungetc as the first read buffer # operation uses a buffer that is preserved during # seek operations f.ungetc('a') # Character buffer will not be cleared f.seek(2, :SET) f.getc # => 'a' end Tempfile.open do |f| f.write('0123456789') f.rewind # Calling #getc before #ungetc uses a # buffer that is not preserved when seeking f.getc f.ungetc('a') # Character buffer will be cleared f.seek(2, :SET) f.getc # => '2' end ``` When transcoding, however, the character buffer is never cleared when seeking: ```ruby require 'tempfile' Tempfile.open(encoding: 'utf-8:utf-16le') do |f| f.write('0123456789') f.rewind f.ungetc('a'.encode('utf-16le')) # Character buffer will not be cleared f.seek(2, :SET) f.getc # => 'a'.encode('utf-16le') end Tempfile.open(encoding: 'utf-8:utf-16le') do |f| f.write('0123456789') f.rewind f.getc f.ungetc('a'.encode('utf-16le')) # Character buffer will not be cleared f.seek(2, :SET) f.getc # => 'a'.encode('utf-16le') end ``` I would expect the buffers to be cleared in all cases except possibly when the seek operation doesn't actually move the file pointer such as when calling IO#pos or IO#seek(0, :CUR). The inconsistent behavior demonstrated here is a problem regardless though. -- https://bugs.ruby-lang.org/

3 12