The ignore_eof setting on HTTPResponse makes it so an EOFError is
raised when reading bodies with a defined Content-Length, if the
body read was truncated due to the socket be closed.
The ignore_eof setting on HTTP sets the values used in responses
that are created by the object.
For backwards compatibility, the default is for both settings is
true. However, unless you are specifically tested for and handling
truncated responses, it's a good idea to set ignore_eof to false so
that errors are raised for truncated responses, instead of those
errors silently being ignored.
Fixes [Bug #14972]
https://github.com/ruby/net-http/commit/4d47e34995
Bundler vendors this file and we have some tools to automatically
prepend the `Bundler::` namespace so that the vendored version does not
collide with the stdlib version.
However, due to how methods are defined, it's hard for our vendoring
tool to do the right thing.
I think this makes the code simpler and things easier for us too.
https://github.com/ruby/tsort/commit/7088a7c814
Treats:
#fixed_encoding?
#hash
#==
#=~
#match
#match?
Also, in regexp.rdoc:
Changes heading from 'Special Global Variables' to 'Regexp Global Variables'.
Add tiny section 'Regexp Interpolation'.
Previously in some when classes were duped (specifically those with a
prepended module), they would not correctly have their "superclasses"
array or depth filled in.
This could cause ancestry checks (like is_a? and Module comparisons) to
return incorrect results.
This happened because rb_mod_init_copy builds origin classes in an order
that doesn't have the super linked list fully connected until it's
finished. This commit fixes the previous issue by calling
rb_class_update_superclasses before returning the cloned class. This is
similar to what's already done in make_metaclass.
We were trying to remove directories using `FileUtils.rm_f` which is
unexpected and does not remove anything. Changing to `FileUtils.rm_rf`
actually removes the directories properly. That itself showed other
issues:
* One test was actually removing the gem package it was about to
install, since it was living in the cache folder. To fix that, avoid
removing the cache folder, and only make sure the other directories
are created automatically, which seems enough.
* Another test was actually removing an incorrect directory. Change it
to remove the right one (the one that's asserted later to have been
created).
https://github.com/rubygems/rubygems/commit/5538e7ff20
Maybe not the best idea for CI stability to use development versions of
Clang, but that does give us a preview of what's coming and gives us a
chance to make suggestions upstream.