| Age | Commit message (Collapse) | Author |
|---|
|
platforms
https://github.com/rubygems/rubygems/commit/f3c49ad3f7
|
|
Gem::Dependency and Bundler::Dependency
https://github.com/rubygems/rubygems/commit/971d57cf5a
|
|
RDoc is implemented as soft dependency in IRB. See how the rdoc is required in
the files. I reverted the commit below.
```
$ grep -ril rdoc lib/
lib/irb/cmd/help.rb
lib/irb/completion.rb
lib/irb/easter-egg.rb
lib/irb/input-method.rb
```
---
Revert "Remove `require` in signal handler to avoid ThreadError"
This reverts commit https://github.com/ruby/irb/commit/5f749c613c89.
https://github.com/ruby/irb/commit/b24852058f
|
|
Recently a changed was introduced to update the resolver platforms after
it has been created, in order to remove the "ruby" platform from it if
it's to be removed from the lockfile. However, it did not update the
`@resolving_only_for_ruby` instance variable in that case, so the
resolver was not properly doing the right thing anymore.
To fix this, I tweaked the code to restore not changing resolver
platforms after the resolver has been instantiated.
https://github.com/rubygems/rubygems/commit/8fbc30a1d0
|
|
https://github.com/rubygems/rubygems/commit/703373b41f
Co-authored-by: Loic Nageleisen <loic.nageleisen@gmail.com>
|
|
This has been introduced in https://github.com/ruby/irb/commit/026700499dfd,
but it seems that this is just be mistake, otherwise the later handling
of `LoadError` would not be needed.
https://github.com/ruby/irb/commit/54c8df06ff
|
|
force is true
... instead of any StandardError.
To behave like the standard `rm` command, it should only ignore
exceptions about not existing files, not every exception. This should
make debugging some errors easier, because the expectation is that `rm
-rf` will succeed if and only if, all given files (previously existent
or not) are removed. However, due to this exception swallowing, this is
not always the case.
From the `rm` man page
> COMPATIBILITY
>
> The rm utility differs from historical implementations in that the -f
> option only masks attempts to remove non-existent files instead of
> masking a large variety of errors.
https://github.com/ruby/fileutils/commit/fa65d676ec
Co-Authored-By: David Rodríguez <deivid.rodriguez@riseup.net>
|
|
The ensure in postorder_traverse was added for [Bug #6756].
The intention was to try to delete the parent directory if it failed to
get the children. (It may be possible to delete the directory if it is
empty.)
However, the ensure region rescue'ed not only "failure to get children"
but also "failure to delete each child". Thus, the following raised
Errno::ENOTEMPTY, but we expect it to raise Errno::EACCES.
```
$ mkdir foo
$ touch foo/bar
$ chmod 555 foo
$ ruby -rfileutils -e 'FileUtils.rm_rf("foo")'
```
This changeset narrows the ensure region so that it rescues only
"failure to get children".
https://github.com/ruby/fileutils/commit/ec5d3b84ea
|
|
Also typo is fixed.
Signed-off-by: Takuya Noguchi <takninnovationresearch@gmail.com>
https://github.com/rubygems/rubygems/commit/9c1ea52ddf
|
|
Pick from https://github.com/rubygems/rubygems/commit/6b3a5a9ab0453463381a8164efb6298ea9eb776f
Notes:
Merged: https://github.com/ruby/ruby/pull/6268
|
|
When `--conservative` is passed, explicit unlocks are set for top level
gems via `@unlock[:gems]`, so that only those particular gems are
allowed to be updated.
When we compute the "base resolve" from the lockfile (the set of gems
whose versions should be kept pinned by the resolver), we always exclude
gems explicitly unlocked through `@unlock[:gems]` from it. This is done
by the `converge_specs` method.
However, the `converge_specs` method is also used for figuring out
additional lower bound requirements from the lockfile. But in this case,
even if gems are explicitly unlock in `@unlock[:gems]`, we still want to
add the additional requirement, so that gems are not downgraded by the
resolver.
So the solution is to move the line filtering out gems in
`@unlock[:gems]` from the `converged_specs` method out of that method,
so that it only applies for computing the "base resolve", but not the
addtional lower bound requirements.
https://github.com/rubygems/rubygems/commit/405119bd7b
Notes:
Merged: https://github.com/ruby/ruby/pull/6268
|
|
https://github.com/rubygems/rubygems/commit/fa60f1fe43
Notes:
Merged: https://github.com/ruby/ruby/pull/6268
|
|
It's already included by the parent.
https://github.com/rubygems/rubygems/commit/3ffe389c44
Notes:
Merged: https://github.com/ruby/ruby/pull/6268
|
|
It's explicitly loaded when monkeypatching RubyGems, which we do very
early. So neither autoloading it, nor explicitly loading it anywhere
else is necessary.
https://github.com/rubygems/rubygems/commit/fbc7a57161
Notes:
Merged: https://github.com/ruby/ruby/pull/6268
|
|
https://github.com/rubygems/rubygems/commit/7e976d790a
|
|
https://github.com/rubygems/rubygems/commit/1b9f7f50a5
|
|
Attempting to install a gem published as both *-linux and *-linux-musl
results in the incorrect gem being picked up, causing build failures due
to binary incompatibility. This is caused by the `nil` wildcard
swallowing the libc information upon version comparison.
Handle the linux case by performing only non-wildcard equality on the
version and asserting 'gnu' and nil equivalence, while preserving the
current behaviour for other OSes.
https://github.com/rubygems/rubygems/commit/9eead86abc
Co-authored-by: Loic Nageleisen <loic.nageleisen@gmail.com>
|
|
The symmetry with the "for command line" case is made more apparent.
https://github.com/rubygems/rubygems/commit/ab85d3558f
|
|
on a offline drive
https://github.com/ruby/fileutils/commit/9cc6a082d7
|
|
skips install
If the application has the `no_install` setting set for `bundle
package`, then `bundler/inline` would silently skip installing any gems.
https://github.com/rubygems/rubygems/commit/7864f49b27
|
|
no Ruby locked
https://github.com/rubygems/rubygems/commit/49fc54e87d
|
|
ArgumentError
https://github.com/ruby/error_highlight/commit/defcaf1beb
|
|
```
$ tool/sync_default_gems.rb syntax_suggest
```
Notes:
Merged: https://github.com/ruby/ruby/pull/5859
|
|
[Feature #18822]
Ruby is somewhat missing an RFC 3986 compliant escape method.
https://github.com/ruby/cgi/commit/c2729c7f33
|
|
https://github.com/rubygems/rubygems/commit/0d321c9e3a
|
|
ErrorHighlight.spot
https://github.com/ruby/error_highlight/commit/489ce80a62
|
|
https://github.com/ruby/error_highlight/commit/6edf0a0a5d
|
|
We had to keep backtrace_location before opts is overwritten.
https://github.com/ruby/error_highlight/commit/2735e4681a
|
|
(https://github.com/ruby/error_highlight/pull/25)
... and move things from core_ext.rb to base.rb.
This will confine CRuby-dependent things to ErrorHighlight.spot.
https://github.com/ruby/error_highlight/commit/22d1dd7824
|
|
Pick from https://github.com/rubygems/rubygems/commit/dfbb5a38114640e0d8d616861607f3de73ee0199
Notes:
Merged: https://github.com/ruby/ruby/pull/6224
|
|
https://github.com/ruby/ruby/commit/e4e054e3ce40 used four footnotes
without blank lines. And the ChangeLog generated from that commit
resulted in ``undefined method `parts' for nil`` error.
For now, let a footnote terminated by the next footnote mark.
Also refined the error message when undefined footnote is used.
https://github.com/ruby/rdoc/commit/a7f290130b
|
|
(https://github.com/ruby/rdoc/pull/910)
https://github.com/ruby/rdoc/commit/4e44c9c6cf
|
|
gems are unlocked
This is a regression from a change intended to raise errors when user
puts a gem under an incorrect source in the Gemfile by mistake. To fix
the issue, we revert the change that caused it and implement it in a
different way that restores the resolver independency from real
specifications. Now it deals only with names and versions and does not
try to materialize anything into real specifications before resolving.
https://github.com/rubygems/rubygems/commit/d2bf1b86eb
|
|
https://github.com/rubygems/rubygems/commit/d60acdf80d
|
|
https://github.com/rubygems/rubygems/commit/3a843c1ac7
|
|
https://github.com/rubygems/rubygems/commit/9dbc4757a8
|
|
https://github.com/rubygems/rubygems/commit/3cc3bfd371
|
|
https://github.com/rubygems/rubygems/commit/69d0b4e10b
|
|
For the macOS -bundle_loader linker option, we need a path to the
Ruby exectuable. $(RUBY) is not necessarily a path since it could
be a command line invocation. That happens during build with
runruby.rb and can happen post installation if the user passes
the --ruby option to a extconf.rb. Use $(bindir) to locate
the executable instead.
Before installation, $(bindir) doesn't exist, so we need to be
able to override $(BUILTRUBY) in such situations so test-spec
and bundled extensions could build. Use a new mkmf global,
$builtruby, to do this; set it in fake.rb and in extmk.rb.
Our build system is quite complex...
Notes:
Merged: https://github.com/ruby/ruby/pull/6193
|
|
ld64 shipped with Xcode 14 emits a warning when using `-undefined
dynamic_lookup`.
```
ld: warning: -undefined dynamic_lookup may not work with chained fixups
```
Actually, `-undefined dynamic_lookup` doesn't work when:
1. Link a *shared library* with the option
2. Link it with a program that uses the chained-fixup introduced from
macOS 12 and iOS 15
because `-undefined dynamic_lookup` uses lazy-bindings and they won't be
bound while dyld fixes-up by traversing chained-fixup info.
However, we build exts as *bundles* and they are loaded only through
`dlopen`, so it's safe to use `-undefined dynamic_lookup` in theory.
So the warning produced by ld64 is false-positive, and it results
failure of option checking in configuration. Therefore, it would be an
option to ignore the warning during our configuration.
On the other hand, `-undefined dynamic_lookup` is already deprecated on
all darwin platforms except for macOS, so it's good time to get rid of
the option. ld64 also provides `-bundle_loader <executable>` option,
which allows to resolve symbols defined in the executable symtab while
linking. It behaves almost the same with `-undefined dynamic_lookup`,
but it makes the following changes:
1. Require that unresolved symbols among input objects must be defined
in the executable.
2. Lazy symbol binding will lookup only the symtab of the bundle loader
executable. (`-undefined dynamic_lookup` lookups all symtab as flat
namespace)
This patch adds `-bundle_loader $(RUBY)` when non-EXTSTATIC
configuration by assuming ruby executable can be linked before building
exts.
See "New Features" subsection under "Linking" section for chained fixup
https://developer.apple.com/documentation/xcode-release-notes/xcode-13-release-notes
Notes:
Merged: https://github.com/ruby/ruby/pull/6193
|
|
https://github.com/rubygems/rubygems/commit/425b78637f
|
|
https://github.com/rubygems/rubygems/commit/3973773005
|
|
https://github.com/ruby/irb/commit/8a074a6904
|
|
It should be an alias of `--filter-strict`.
`--update-strict` is essentially a dummy option with no special behavior
associated and should be deprecated.
https://github.com/rubygems/rubygems/commit/ec1e5d83c8
|
|
https://github.com/rubygems/rubygems/commit/c9a1d69a8d
|
|
Pick from https://github.com/rubygems/rubygems/commit/8331e63263081a6aa690d8025d2957f30c4e814a
Notes:
Merged: https://github.com/ruby/ruby/pull/6209
|
|
https://github.com/rubygems/rubygems/commit/f087f1b590
|
|
specification versions
https://github.com/rubygems/rubygems/commit/a4ba1a4d97
|
|
https://github.com/rubygems/rubygems/commit/3212ae14b7
|
|
Signed-off-by: Takuya Noguchi <takninnovationresearch@gmail.com>
https://github.com/rubygems/rubygems/commit/3e62ca776d
|
