| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
/test/rubygems/test_gem_ext_cargo_builder/custom_name
Bumps [rb-sys](https://github.com/ianks/rb-sys) from v0.7.3 to v0.9.0.
- [Release notes](https://github.com/ianks/rb-sys/releases)
- [Commits](https://github.com/ianks/rb-sys/compare/4a5dd9782075fc6e197976eb2188231a388c3c95...https://github.com/rubygems/rubygems/commit/e4f00b9761af)
---
updated-dependencies:
- dependency-name: rb-sys
dependency-type: direct:production
...
Signed-off-by: dependabot[bot] <support@github.com>
https://github.com/rubygems/rubygems/commit/874bbc96b2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In principle, we have a DTrace probe in yjit.c, so yjit.o should be
in DTRACE_DEPENDENT_OBJS for DTRACE_REBUILD=yes builds. This commit
adds to the list.
In practice DTRACE_REBUILD=yes implies the system has a Solaris-like
DTrace and YJIT doesn't support those systems. YJIT_OBJ expands to
nothing, and yjit.c isn't compiled.
I tested on OmniOS v11 r151034m with:
$ ../src/configure --with-out-ext=psych MAKE=gmake AR=ar debugflags=-g
$ gmake -j
It builds before and after this change.
[Bug #18480]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bumps [rb-sys](https://github.com/ianks/rb-sys) from v0.7.3 to v0.9.0.
- [Release notes](https://github.com/ianks/rb-sys/releases)
- [Commits](https://github.com/ianks/rb-sys/compare/4a5dd9782075fc6e197976eb2188231a388c3c95...https://github.com/rubygems/rubygems/commit/e4f00b9761af)
---
updated-dependencies:
- dependency-name: rb-sys
dependency-type: direct:production
...
Signed-off-by: dependabot[bot] <support@github.com>
https://github.com/rubygems/rubygems/commit/eb31b14a37
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`vm_trace_hook()` runs global hooks before running local hooks.
Previously, we read the local hook list before running the global hooks
which led to use-after-free when a global hook frees the local hook
list. A global hook can do this by disabling a local TracePoint, for
example.
Delay local hook list loading until after running the global hooks.
Issue discovered by Jeremy Evans in GH-5862.
[Bug #18730]
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Treats:
::copy_entry
::copy_file
::copy_stream
::mv
https://github.com/ruby/fileutils/commit/d6d7e5330d
|
| |
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/2d99277328
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If BUNDLE_PATH is configured to a symlinked path, installing gems with
symlinks would crash with an error like this:
```
Gem::Package::SymlinkError: installing symlink 'man/man0/README.markdown' pointing to parent path /usr/home/stevewi/srv/mail/lib/tools/.vendor/ruby/3.1.0/gems/binman-5.1.0/README.markdown of /srv/mail/lib/tools/.vendor/ruby/3.1.0/gems/binman-5.1.0 is not allowed
```
This commit fixes the problem by changing the bundle path to be the
realpath of the configured value, right after we're sure the path has
been created.
https://github.com/rubygems/rubygems/commit/3cd3dd142a
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/70ff7cee9f
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/8e68c57457
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/f5dd5204ca
|