| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously `(2..).cover?("2"..)` was false, but
`(..2).cover?(.."2")` was true. This changes it so both are false,
treating beginless ranges the same as endless ranges in regards to
type checks.
This also adds documentation to #cover? to describe behavior with
beginless and endless ranges, testing each documentation example,
which is how this bug was found.
Fixes [Bug #18155]
|
|
|
|
|
| |
Implements [Feature #12655]
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(https://github.com/ruby/fileutils/pull/78)
Treats:
::rm
::rm_f
::rm_r
::rm_rf
::remove_entry_secure
https://github.com/ruby/fileutils/commit/ce2a438d75
|
| |
|
|
|
|
|
|
| |
* Add missing slash.
https://github.com/ruby/open-uri/commit/40023e63da
|
|
|
|
| |
https://github.com/ruby/rdoc/commit/fec1ab2e41
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was being explicitly required from `Gem::Specification` but also a
strange autoload was set for it at `Gem::Version`. The autoload was non
standard because it should've been done in the `Gem` module, not in
`Gem::Specification`, since that's where the constant is expected to get
defined. Doing this might get deprecated in the future, and it was not
being effective anyways due to the explicit require.
Unify everything with an `autoload` at the right place.
https://github.com/rubygems/rubygems/commit/174ea3e24c
|
| |
|
|
|
|
| |
https://github.com/ruby/cgi/commit/93326fb622
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The tests fail randomly on some platforms.
http://rubyci.s3.amazonaws.com/ubuntu/ruby-master/log/20220605T213004Z.fail.html.gz
http://rubyci.s3.amazonaws.com/arch/ruby-master/log/20220605T210003Z.fail.html.gz
```
[15737/21701] TestThreadInstrumentation#test_thread_instrumentation_fork_safe/home/chkbuild/chkbuild/tmp/build/20220605T213004Z/ruby/tool/lib/test/unit/assertions.rb:109:in `assert': Expected 0 to be nonzero?. (Test::Unit::AssertionFailedError)
```
The failures seem to depend on context switches. I suspect `sleep 0.05`
is too short, so this change tries to extend the wait time.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
THREAD_MODEL is exported already, so this matches that. Exporting this
is simpler than inspecting configure_args and arch and matching that up
with a specific configure.ac.
Fix GH-5976
|
| |
|
| |
|
|
|
|
|
|
| |
So that an exception raises by non-existent command, not via shell.
https://github.com/ruby/rdoc/commit/fd94dce69d
|
|
|
|
| |
https://github.com/ruby/rdoc/commit/6b1a011243
|
|
|
|
| |
https://github.com/ruby/rdoc/commit/83051403d6
|
|
|
|
| |
https://github.com/ruby/rdoc/commit/ce63794fde
|
|
|
|
|
|
| |
`IO.popen` does that job.
https://github.com/ruby/rdoc/commit/3bbbc5ac84
|
|
|
|
| |
https://github.com/ruby/rdoc/commit/47a1aef447
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In the event that we are crashing due to a corrupt Ruby stack, we might
re-enter rb_vm_bugreport() due to failed assertions in
rb_backtrace_print_as_bugreport() or SDR(). In these cases we were
printing the bug report ad infinitum with unbounded recusion.
I seem to run into this every once in a while and the amount of log it
prints out is pretty distracting. On CI environments it makes the log
output unnecessarily big. Let's fix this.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ref: https://bugs.ruby-lang.org/issues/18339
Design:
- This tries to minimize the overhead when no hook is registered.
It should only incur an extra unsynchronized boolean check.
- The hook list is protected with a read-write lock as to cause
contention when some hooks are registered.
- The hooks MUST be thread safe, and MUST NOT call into Ruby as they
are executed outside the GVL.
- It's simply a noop on Windows.
API:
```
rb_internal_thread_event_hook_t * rb_internal_thread_add_event_hook(rb_internal_thread_event_callback callback, rb_event_flag_t internal_event, void *user_data);
bool rb_internal_thread_remove_event_hook(rb_internal_thread_event_hook_t * hook);
```
You can subscribe to 3 events:
- READY: called right before attempting to acquire the GVL
- RESUMED: called right after successfully acquiring the GVL
- SUSPENDED: called right after releasing the GVL.
The hooks MUST be threadsafe, as they are executed outside of the GVL, they also MUST NOT call any Ruby API.
|
|
|
|
| |
https://github.com/ruby/nkf/commit/b386ddc11c
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/a20bac7924
|
|
|
|
|
|
|
|
|
|
| |
message
I found that the current test cases did not cover the bitwise AND
performed on modified words after each iteration
(https://github.com/rubygems/rubygems/blob/7e5765a66c9fe5187b167f619f34db5db121f2df/bundler/lib/bundler/digest.rb#L50)
https://github.com/rubygems/rubygems/commit/c8de819fee
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/7c6f15040d
|
| |
|
|
|
|
|
| |
Define `GC.verify_compaction_references` as a built-in ruby method,
according to GC compaction support via `GC::OPTS`.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Also add jhawthorn's test to for this bug.
Fix String#to_s invalidation test
|
|
|
|
|
|
|
|
|
|
|
|
| |
`Bundle.defintion`.
Prior to this commit, `bundle add GEM_NAME` updated the lockfile,
but `bundle remove GEM_NAME` left GEM_NAME in the lockfile.
By invalidating the cached `Bundle.definition`, the existing code
handles that without a problem.
https://github.com/rubygems/rubygems/commit/aa0794d6a9
|
|
|
|
|
|
|
|
|
|
|
| |
The installer is actually rewriting the spec's full gem path to be the
one of the newly installed gem, however the accessor was not properly
working for `StubSpecification` instances, and default gems are always
of this type, because they are always present locally.
Fix the accessor to properly update the underlying full specification.
https://github.com/rubygems/rubygems/commit/efa41babfa
|
|
|
|
|
|
|
|
| |
This change was never covered with a spec, and we have recently covered
the case of partially deleted gems with specs and it works fine
(installation is "auto-healed").
https://github.com/rubygems/rubygems/commit/6e66ee4235
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`YAML::PrivateType`
This issue was not detected because when all traces of old YAML parser
and emitter `Syck` were removed, this null-type.gemspec.rz marshalled
gemspec was updated to no longer load `YAML::Syck::PrivateType` but load
`Psych::PrivateType` instead.
However, realworld old marshalled gemspecs still use the
`YAML::PrivateType` constant, so this commit replaces the gemspec to be
the real pry-0.4.7 marshalled gemspec, so that it catches this issue.
https://github.com/rubygems/rubygems/commit/51b330b8d2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This test is making sure that RubyGems is able to load old marshalled
gemspecs that include a field loading `YAML::PrivateType` instances in
the `rubyforge_project` field instead of `nil` due to a bug in old YAML
emitters.
At some point, the `rubyforge_project` field was removed and this test
was updated to just check another field. However, in the realworld other
fields do not have this issue and the marshalled gemspec we use for
testing still has this issue in the field reserved for the
`rubyforge_project` field. So I think updating the test to check other
field was not correct.
Instead, since the `rubyforge_project` field is now ignored, we no
longer need to worry about any conversion in this field. The only thing
we care about is that the marshal loading still works (which requires
that the constant is at least defined).
So this commit updates the test to make this more clear.
https://github.com/rubygems/rubygems/commit/cddfacf6d4
|
|
|
|
|
|
|
|
|
|
|
|
| |
This old bug used to affect the `rubyforge_project` field in serialized
gemspecs. However, this field has been removed and it's no longer
present in marshaled loaded gemspecs.
So, while the constant is still present in these marshalled gemspecs and
we still need to make sure it exists, we no longer need to clean it up
from the loaded data.
https://github.com/rubygems/rubygems/commit/09df18e522
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Generally this warning is skipped for gemspec development dependencies.
I think because it's common to override them in the Gemfile to change
the source, for example.
But the order of conditions was not correct and the warning was still
being printed in one case.
https://github.com/rubygems/rubygems/commit/da9d1d6a3f
|
|
|
|
|
|
|
|
| |
This alternative really uses only the Gemfile, and can never end up
being absurd, because it will never be suggested when there's no
lockfile, and it suggests deleting the lockfile.
https://github.com/rubygems/rubygems/commit/5d154dd50e
|
|
|
| |
Add information from doc/hacking.md and doc/make_cheatsheet.md back into contributing docs
|