This is hiding a real bundler issue as a "network error". It's more
helpful to get a proper bug report, with stack trace and so on.
So stop re-raising errors when evaluating unmarshaled responses as
network errors, and only raise Marshal errors when the Marshal format is
invalid, not whenever marshalled gemspecs can't be loaded because that
may hide actual client errors, like missing `YAML` constants.
https://github.com/rubygems/rubygems/commit/05ea907e1c
Properly set the name of `File::Constants`, which is the only name
with a namespace in `RDoc::KNOWN_CLASSES`, and fixes longstanding bug
that `File::Constants` becomes `File::File::Constants`.
When it is generated by `rb_file_const` in dir.c, `name` is set to the
qualified name as same as `full_name`, and generated in the normal way
in file.c later, already set `full_name` is cleared and `name` will be
constructed from the enclosing namespace and the `name`. It will
results in duplicated namespace, `File::File::Constants`.
https://github.com/ruby/rdoc/commit/3a8d6df562
The note
> Raises an ArgumentError if the given +orig+ is immutable, such as Symbol,
> Integer, or Float.
has not been true since #2313 (GH-2313, Feature #16035) when
@casperisfine enabled storing non-finalizable objects in the underlying
`ObjectSpace::WeakMap`.
On Ruby 2.7+, `WeakRef.new(1) + 1` works fine and the result is the
expected 2.
For example, consider the following markup:
C1#m(a, b)
Before this patch, it generated this HTML:
<p><a href=\"C1.html#method-i-m\"><code>C1#m</code></a>(a, b)</p>
Which places the method arguments outside of the link.
Now it generates this HTML:
<a href=\"C1.html#method-i-m\"><code>C1#m(a, b)</code></a>
https://github.com/ruby/rdoc/commit/05a2b2222b
When I run bundle install with BUNDLE_DEPLOYMENT=true in the environment
on a different platform than I usually do development, I get the
following output to the console (wrapped exactly as shown):
Your bundle only supports platforms ["x86_64-darwin-19"] but your local platform
is x86_64-linux. Add the current platform to the lockfile with `bundle lock
--add-platform x86_64-linux` and try again.
Because the way the message wraps, its not as simple as copying the
suggested command to the clipboard because it contains a newline:
$ bundle lock
Writing lockfile to [...]/Gemfile.lock
$ --add-platform x86_64-linux
Adding a newline right before the command forces the command in the
error message to be on the same line, which facilitates copy-pasting the
command in the message.
https://github.com/rubygems/rubygems/commit/4cf6989b11
Previously they had slightly different behavior when combined with
conservative updating flags.
The correct behavior is the `--update-strict` option, so `--script` now
does that, The `--update-strict` option is left there for now but I will
deprecate it later.
https://github.com/rubygems/rubygems/commit/ab42046229
The existing implementation, given the below .inputrc, erroneously
creates a "C-v" key binding:
set keymap emacs-ctlx
"\C-v": "[C-x C-v was pressed]"
This fixes it to instead create a "C-x C-v" keybinding.
https://github.com/ruby/reline/commit/719f52d231
This patch makes sure we only load relative code. Hence when coding or
testing rdoc, we'll be sure to always be using the correct code.
Discussion started at https://github.com/ruby/rdoc/pull/817.
Signed-off-by: Ulysse Buonomo <buonomo.ulysse@gmail.com>
https://github.com/ruby/rdoc/commit/aa41bd48eb
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
This improves the performance in some cases.
`rdoc .../gems/sinatra-2.1.0/README.md` takes 10.5 sec. before this
change, and 7.1 sec. after this change.
`make rdoc` of ruby/ruby takes 19.3 sec. before this change, 18.1 sec.
after this change.
https://github.com/ruby/rdoc/commit/7cf8281e3e
