| Age | Commit message (Collapse) | Author |
|
|
|
|
|
slight adjustments
(https://github.com/ruby/irb/pull/811)
https://github.com/ruby/irb/commit/6a9193e88b
|
|
ForwardingSuperNodes need to actually forward any applicable
arguments. This commit implements that logic, by using the data
stored on the local iseq about the parameters to forward the
appropriate arguments.
|
|
Prior to this commit, if a rest parameters was `*`, we did not add
it to the locals table correctly. This commit fixes that.
|
|
https://github.com/ruby/prism/commit/1e07832778
|
|
|
|
https://github.com/ruby/prism/commit/5f05a6fe83
|
|
https://github.com/ruby/prism/commit/e5f37d1407
|
|
And make it easier to update next time.
https://github.com/rubygems/rubygems/commit/1ea4bfa5d8
|
|
https://github.com/ruby/prism/commit/465731969c
|
|
Examples of such calls:
```ruby
obj[kw: 1] += fo
obj[**kw] &&= bar
```
Before this patch, literal keywords would segfault in the compiler,
and keyword splat usage would result in TypeError.
This handles all cases I can think of:
* literal keywords
* keyword splats
* combined with positional arguments
* combined with regular splats
* both with and without blocks
* both popped and non-popped cases
This also makes sure that to_hash is only called once on the keyword
splat argument, instead of twice, and make sure it is called before
calling to_proc on a passed block.
Fixes [Bug #20051]
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
|
|
https://github.com/rubygems/rubygems/commit/2dca83722b
|
|
It makes code formatters confused when auto indenting.
|
|
During allocation, the table may not have been allocated yet which would
crash in the st_foreach.
|
|
During allocation, the table may not have been allocated yet which would
crash in the st_foreach.
|
|
https://github.com/ruby/prism/commit/0663e2bcfa
|
|
element that should clear it
https://github.com/ruby/prism/commit/7c7c486507
|
|
https://github.com/ruby/prism/commit/aa83de39c1
|
|
https://github.com/rubygems/rubygems/commit/0cbbaed8a5
|
|
This is required to fix ruby/ruby's CI
https://github.com/ruby/irb/commit/3c77213209
|
|
(https://github.com/ruby/irb/pull/738)
[DOC] RDoc for module IRB
https://github.com/ruby/irb/commit/f3a0626298
|
|
This _partially_ reverts commit
d2ba8ea54a4089959afdeecdd963e3c4ff391748, but for UDP sockets only.
With TCP sockets (and other things which use `rsock_init_inetsock`), the
order of operations is to call `getaddrinfo(3)` with AF_UNSPEC, look at
the returned addresses, pick one, and then call `socket(2)` with the
family for that address (i.e. AF_INET or AF_INET6).
With UDP sockets, however, this is reversed; `UDPSocket.new` takes an
address family as an argument, and then calls `socket(2)` with that
family. A subsequent call to UDPSocket#connect will then call
`getaddrinfo(3)` with that family.
The problem here is that...
* If you are in a networking situation that _only_ has loopback addrs,
* And you want to look up a name like "localhost" (or NULL)
* And you pass AF_INET or AF_INET6 as the ai_family argument to
getaddrinfo(3),
* And you pass AI_ADDRCONFIG to the hints argument as well,
then glibc on Linux will not return an address. This is because
AI_ADDRCONFIG is supposed to return addresses for families we actually
have an address for and could conceivably connect to, but also is
documented to explicitly ignore localhost in that situation.
It honestly doesn't make a ton of sense to pass AI_ADDRCONFIG if you're
explicitly passing the address family anyway, because you're not looking
for "an address for this name we can connect to"; you're looking for "an
IPv(4|6) address for this name". And the original glibc bug that
d2ba8ea5 was supposed to work around was related to parallel issuance of
A and AAAA queries, which of course won't happen if an address family is
explicitly specified.
So, we fix this by not passing AI_ADDRCONFIG for calls to
`rsock_addrinfo` that we also pass an explicit family to (i.e. for
UDPsocket).
[Bug #20048]
|
|
|
|
https://github.com/ruby/securerandom/commit/ddf2672e47
|
|
https://github.com/ruby/securerandom/commit/9a99978135
|
|
https://github.com/ruby/securerandom/pull/19/files#r1329476195
https://github.com/ruby/securerandom/commit/156cbb8448
|
|
If no block is given, return 0 instead of nil for consistency
with Dir.chdir and Dir.fchdir.
|
|
|
|
install
https://github.com/rubygems/rubygems/commit/6847709ee0
|
|
|
|
Also fix running when BUNDLE_NO_INSTALL happens to be set, same as with install/update commands
https://github.com/rubygems/rubygems/commit/a555fd6ccd
|
|
|
|
|
|
|
|
|
|
|
|
... to disable a warning: assigned but unused variable - expected
|
|
https://github.com/rubygems/rubygems/commit/119d4bdc09
|
|
https://github.com/rubygems/rubygems/commit/2720da2659
|
|
https://github.com/rubygems/rubygems/commit/fd2e71dfdb
|
|
|
|
https://github.com/rubygems/rubygems/commit/c241a88962
|
|
https://github.com/rubygems/rubygems/commit/3355c80c90
|
|
https://github.com/rubygems/rubygems/commit/8a936d733d
|
|
https://github.com/rubygems/rubygems/commit/7be5b40ca9
|
|
I think we can safely assume these days that all RubyGems and Bundler
versions that will ever bundle a new gem created in 2023 support
prereleases.
So this non transparent requirement is not necessary.
In my opinion, it should be the gem author to explicitly add this
constraint, not RubyGems.
https://github.com/rubygems/rubygems/commit/b165e6d725
|
|
https://github.com/rubygems/rubygems/commit/4b4d9c0106
|
|
already a default gem
https://github.com/rubygems/rubygems/commit/620119308e
|
|
https://github.com/rubygems/rubygems/commit/48bc573310
|