Project

General

Profile

Actions
Copy link

Misc #21281

closed
Actions
Copy link
#1

Updated by mame (Yusuke Endoh) about 2 months ago

  • Related to : [META] DevelopersMeeting added
Actions
Copy link
#2 [ruby-core:121714]

Updated by byroot (Jean Boussier) about 2 months ago · Edited

  • [Feature ] Actually deprecate ObjectSpace._id2ref (byroot)
Actions
Copy link
#3 [ruby-core:121788]

Updated by tagomoris (Satoshi Tagomori) about 2 months ago · Edited

  • [Feature ] Namespace on read (tagomoris)
    • I'm finishing the namespace branch to be ready for merge (disabled by default) https://.com/tagomoris/ruby/tree/namespace-on-read-classext
    • Current status:
      • Default (Namespace disabled, YJIT/ZJIT disabled): make check and make exam passed on my macOS (not checked on CI)
      • Namespace enabled: make check passed but make exam failed (the known cause and I'll update the implementation soon)
    • I hope it'll be merged without further more rebases :P
Actions
Copy link
#4 [ruby-core:121805]

Updated by jeremyevans0 (Jeremy Evans) about 2 months ago

  • [Feature ] Show performance warnings for easily avoidable unnecessary implicit splat allocations (jeremyevans0)
    • This warning only shows method calls that are allocating unnecessarily, where allocation can be avoided by using a local variable.
    • This warning found unnecessary allocations in the standard library, rubygems, Rails, and Sequel.
    • We are currently only using performance warnings for objects with too many shapes.
    • Is this OK to commit?
  • [Feature ] Remove SortedSet autoload and set/sorted_set (jeremyevans0)
    • Set is now a core class, and the SortedSet autoload that was in set.rb is now in core.
    • This autoload only works if the sorted_set gem is installed.
    • I don't think we should have this autoload, can we remove it?
    • If so, do we want to deprecate the autoload before removing it?
  • [Bug ] Remove or Fix Set#to_h (jeremyevans0)
    • The method was not present in stdlib Set, and not previously approved for addition.
    • However, psych started using it.
    • The method is not backwards compatible with the previous Set#to_h (implemented by Enumerable#to_h).
    • I recommend we remove it and fix psych, and have a pull request for that.
    • If we want to keep it, I have a pull request to fix it, and add tests and documentation.
    • Do we want to keep Set#to_h and have a return a true-valued hash if not given a block?
  • [Bug ] StringIO#set_encoding warns when backed by chilled string literal (jeremyevans0)
    • This warning is bogus, as most code using this does not need changes when string literals are frozen.
    • Issuing bogus warnings prompts for unnecessary code changes and should be avoided.
    • StringIO#set_encoding already does not set the encoding if the string is frozen, since [Bug ]
    • I recommend we stop setting the underlying encoding for non-frozen strings to avoid the warning.
    • This could be done for only chilled strings, or for all strings if behavior should be consistent.
    • Should we make this change, and if so, for chilled strings or for both chilled and unfrozen strings?
Actions
Copy link
#5 [ruby-core:121818]

Updated by mame (Yusuke Endoh) about 2 months ago · Edited

  • [Feature ] A way to strictly validate time input (mame)
    • I want to confirm that the current tolerant behavior of Time.new is intentional, and if so, want a strict variant of Time.new.
Actions
Copy link
#6 [ruby-core:121821]

Updated by jhawthorn (John Hawthorn) about 2 months ago

  • [Feature ] respond_to check in Class#allocate is inconsistent
    • Class#allocate does a slow respond_to check to try to prevent uninitialized values via method(:allocate).bind_call on MatchData, Refinement, Module, Complex, Rational
    • The respond_to check is easy to trick and bypass. Even if it was more strict, it does not seem to provide additional safety as there are other ways to construct uninitialized objects.
    • Is it OK to remove?
Actions
Copy link
#7 [ruby-core:121871]

Updated by hsbt (Hiroshi SHIBATA) about 1 month ago · Edited

  • [Feature ] Retire CGI library from Ruby 3.5
    • Can I remove CGI library without CGI::Util ?
    • What's the preferred migration process?
      1. We keep only cgi/escape (C impl)feature in Ruby.
      2. We keep cgi/util with cgi/escape. The current CGI library is removed and depend cgi-util gem.
      3. We migrate cgi/escape to other class/module. The current CGI library and cgi/escape are removed.
      4. We provide cgi-util gem for migration with deprecated warning at Ruby 3.5. In next year, we will remove cgi-util gem.
Actions
Copy link
#8

Updated by Eregon (Benoit Daloze) about 1 month ago

  • Description updated (diff)
Actions
Copy link
#9

Updated by mame (Yusuke Endoh) 15 days ago

  • Status changed from Open to Closed
Actions
Copy link

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0