lambda(&b) where b is given block of method (like: def foo(&b))
should warn correctly.
[Feature #17361]
Also labmda(&labmda_block) or lambda(&:to_s) (Symbol#to_proc)
should not warn (but I'm not sure who cares about it).
I don't use tool/sync_default_gem.rb because the last sync was incomplete.
Co-authored-by: Hiroshi SHIBATA <hsbt@ruby-lang.org>
Co-authored-by: Alan Wu <XrXr@users.noreply.github.com>
Co-authored-by: sinisterchipmunk <sinisterchipmunk@gmail.com>
Co-authored-by: Sutou Kouhei <kou@clear-code.com>
This changes the behavior, which I'm not sure is acceptable.
However, it's odd to allow an option to be combined, but change
the behavior of the option when combined.
This speeds up all instance variable access, even when not in
verbose mode. Uninitialized instance variable warnings were
rarely helpful, and resulted in slower code if you wanted to
avoid warnings when run in verbose mode.
Implements [Feature #17055]
Miller Rabin algorithm can be used to test primality for integers smaller than a max value "MaxMR" (~3e24)
It can be much faster than previous implementation: ~100x faster for numbers with 13 digits, at least 5 orders of magnitude for even larger numbers (previous implementation is so slow that it requires more patience than I have for more precise estimate).
Miller Rabin test becomes faster than previous implementation at somewhere in the range 1e5-1e6. It seems that the range 62000..66000 is where Miller Rabin starts being always faster, so I picked 0xffff arbitrarily; before that, or above "MaxMR", the previous implementation remains.
I compared the `faster_prime` gem too. It is slower than previous implementation up to ~1e4. After that it becomes faster and faster compared to previous implementation, but is still slower than Miller Rabin starting at ~1e5 and up to MaxMR. Thus, after this commit, builtin `Integer#prime?` will be similar or faster than `faster_prime` up to "MaxMR".
Adapted from patch of Stephen Blackstone [Feature #16468]
Benchmark results and code: https://gist.github.com/marcandre/b263bdae488e76dabdda84daf73733b9
Co-authored-by: Stephen Blackstone <sblackstone@gmail.com>
This reverts commit bd47a8d660.
`libc_so` and `libm_so` are `nil` at line 124 because Big Sur doesn't have `/usr/lib/libSystem.B.dylib`.
The reassignment at line 127 is necessary in this case.
* Windows: Read ENV names and values as UTF-8 encoded Strings
Implements issue #12650: fix https://bugs.ruby-lang.org/issues/12650
This also removes the special encoding for ENV['PATH'] and some
complexity in the code that is unnecessary now.
* Windows: Improve readablity of getenv() encoding
getenv() did use the expected codepage as an implicit parameter of the macro.
This is mis-leading since include/ruby/win32.h has a different definition.
Using the "cp" variable explicit (like the other function calls) makes it
more readable and consistent.
* Windows: Change external C-API macros getenv() and execv() to use UTF-8
They used to process and return strings with locale encoding,
but since all ruby-internal spawn and environment functions use UTF-8,
it makes sense to change the C-API equally.
getaddrinfo_a() gets stuck after fork().
To avoid this, we need 1 second sleep to wait for internal
worker threads of getaddrinfo_a() to be finished, but that is unacceptable.
[Bug #17220] [Feature #17134] [Feature #17187]
Avoiding recursive call would imply iterating bits starting from
most significant, which is not easy to do efficiently.
Any saving would be dwarfed by the multiplications anyways.
[Feature #15233]
