Object Shapes is used for accessing instance variables and representing the
"frozenness" of objects. Object instances have a "shape" and the shape
represents some attributes of the object (currently which instance variables are
set and the "frozenness"). Shapes form a tree data structure, and when a new
instance variable is set on an object, that object "transitions" to a new shape
in the shape tree. Each shape has an ID that is used for caching. The shape
structure is independent of class, so objects of different types can have the
same shape.
For example:
```ruby
class Foo
def initialize
# Starts with shape id 0
@a = 1 # transitions to shape id 1
@b = 1 # transitions to shape id 2
end
end
class Bar
def initialize
# Starts with shape id 0
@a = 1 # transitions to shape id 1
@b = 1 # transitions to shape id 2
end
end
foo = Foo.new # `foo` has shape id 2
bar = Bar.new # `bar` has shape id 2
```
Both `foo` and `bar` instances have the same shape because they both set
instance variables of the same name in the same order.
This technique can help to improve inline cache hits as well as generate more
efficient machine code in JIT compilers.
This commit also adds some methods for debugging shapes on objects. See
`RubyVM::Shape` for more details.
For more context on Object Shapes, see [Feature: #18776]
Co-Authored-By: Aaron Patterson <tenderlove@ruby-lang.org>
Co-Authored-By: Eileen M. Uchitelle <eileencodes@gmail.com>
Co-Authored-By: John Hawthorn <john@hawthorn.email>
This list is out of date. At least OpenBSD since 2013 does not
allow one user to read the environment variables of a process
run by another user.
While we could try to keep the list updated, I think it's a bad
idea to not use the user/password from the environment, even if
another user on the system could read it. If http_proxy exists
in the environment, and other users can read it, it doesn't
make it more secure for Ruby to ignore it. You could argue that
it encourages poor security practices, but net/http should provide
mechanism, not policy.
Fixes [Bug #18908]
https://github.com/ruby/net-http/commit/1e4585153d
Previously 9eead86 introduced non-commutativity of platforms, and
later commit 1b9f7f50 changed the behavior of `Gem::Platform.match` to
ensure the callee of `#=~` was the gem platform.
However, when the platform argument is a String, then the callee and
argument of `#=~` are flipped (see docs for `String#=~`), which works
against the fix from 1b9f7f50.
Closes#5938https://github.com/rubygems/rubygems/commit/3b1fb562e8
Object Shapes is used for accessing instance variables and representing the
"frozenness" of objects. Object instances have a "shape" and the shape
represents some attributes of the object (currently which instance variables are
set and the "frozenness"). Shapes form a tree data structure, and when a new
instance variable is set on an object, that object "transitions" to a new shape
in the shape tree. Each shape has an ID that is used for caching. The shape
structure is independent of class, so objects of different types can have the
same shape.
For example:
```ruby
class Foo
def initialize
# Starts with shape id 0
@a = 1 # transitions to shape id 1
@b = 1 # transitions to shape id 2
end
end
class Bar
def initialize
# Starts with shape id 0
@a = 1 # transitions to shape id 1
@b = 1 # transitions to shape id 2
end
end
foo = Foo.new # `foo` has shape id 2
bar = Bar.new # `bar` has shape id 2
```
Both `foo` and `bar` instances have the same shape because they both set
instance variables of the same name in the same order.
This technique can help to improve inline cache hits as well as generate more
efficient machine code in JIT compilers.
This commit also adds some methods for debugging shapes on objects. See
`RubyVM::Shape` for more details.
For more context on Object Shapes, see [Feature: #18776]
Co-Authored-By: Aaron Patterson <tenderlove@ruby-lang.org>
Co-Authored-By: Eileen M. Uchitelle <eileencodes@gmail.com>
Co-Authored-By: John Hawthorn <john@hawthorn.email>
In addition to String values, $LOAD_PATH can also take objects that
respond_to the `to_path` method, like Pathname objects. So `irb` should
be able to handle those objects too.
And if $LOAD_PATH contains objects that can't be converted into String,
`irb` should simply ignore it.
https://github.com/ruby/irb/commit/b2f562176b
The warning against `-undefined dynamic_lookup` is just a warning yet,
and many gems seem to pay no attention to warnings. Until it fails
actually, keep it as a migration path, except for standard extension
libraries and bundled extension gems.
Also add --script option to turn the option back on.
Previously there wasn't a way to get an interactive IRB session
and access arguments provided on the command line.
Additionally, handle `-` as script as stdin. In Unix-like tools, `-`
means to take standard input instead of a file. This doesn't
result in exactly the same output for:
```
echo 'p ARGV' > args.rb; irb args.rb a b c
```
and
```
echo 'p ARGV' | irb - a b c
```
Due to how irb handles whether stdin is a tty.
However, this change allows use of `-` as a argument, instead of
giving an unrecognized switch error. This required some small
changes to context.rb (to handle `-` as standard input) and
input-method.rb (to have FileInputMethod accept IO arguments in
addition to strings).
Implements [Feature #15371]
https://github.com/ruby/irb/commit/4192683ba2
When extracting files from the tarball, a mode is retrieved from
the header. Occasionally you'll encounter a gem that was packaged
on a system whose permission bits result in a value that is larger
than the value that File.chmod will allow (anything >= 2^16). In
that case the extraction fails with a RangeError, which is pretty
esoteric.
If you extract the tarball with the tar and gunzip utilities, the
file permissions end up being just the bottom 16 bits masked off
from the original value. I've mirrored that behavior here. Per the
tar spec:
> Modes which are not supported by the operating system restoring
> files from the archive will be ignored.
I think that basically means what I've done here.
---
This commit also changes the behavior very slightly with regard to
when the chmod is called. Previously it was called while the file
descriptor was still open, but after the write call.
When write flushes, the file permissions are changed to the mode
value from the File.open call, undoing the changes made by
FileUtils.chmod. CRuby appears to flush the buffer after the
chmod call, whereas TruffleRuby flushes before the chmod call.
So the file permissions can change depending on implementation.
Both implementations end up getting the correct file permissions
for the bottom 9 bits (user, group, world), but differ with
regard to the sticky bit in the next 3.
To get consistent behavior, this commit changes it to close the
file descriptor before attempting to chmod anything, which makes
it consistent because the write flushes in both cases.
https://github.com/rubygems/rubygems/commit/22ce076e99
If history file didn't exist when irb was started, @loaded_history_mtime
would be nil. However, if the history file didn't exist before, but it
exists when saving history, that means the history file was modified,
and we should handle it the same way as we handle the other case where
the history file was modified.
Fixes#388https://github.com/ruby/irb/commit/8d277aafcb
I want to use more complicated macros with MJIT. For example:
```
# define SHAPE_MASK (((unsigned int)1 << SHAPE_BITS) - 1)
```
This commit adds a simple recursive descent parser that produces an AST
and a small visitor that converts the AST to Ruby.
I'm thinking about Ruby builtin code instead of doing this.
It'll be hopefully more portable and easier because the same C code could
handle both 32bit and 64bit.
f7cf641469 broke spec/bundler/install/gems/resolving_spec.rb:356.
This line seems to impact that test, so I slightly modified the
implementation for that spec's case.
After recent musl support was added, Bundler started hanging in musl
platforms. I identified the issue where valid candidates were being
filtered out because their platform was specified as a string, and thus
`Gem::Platform.match_spec?` which under the hood ends up calling
`Gem::Platform#===` would return `nil`, because it does not support
comparing platforms to strings.
In particular, `Bundler::EndpointSpecification`'s platform coming from
the API was not instantiated as a `Gem::Platform`, hence the issue.
Also, this spec surfaced another issue where a bug corrected in
`Gem::Platform#match_platforms` had not been yet backported to Bundler.
So this commit also backports that to get the spec green across RubyGems
versions.
Finally, the fix in `Bundler::EndpointSpecification` made a realworld
spec start failing. This spec was faking out `rails-4.2.7.1` requirement
on Bundler in the `Gemfile.lock` file to be `>= 1.17, < 3` when the real
requirement is `>= 1.17, < 2`. Due to the bug in
`Bundler::EndpointSpecification`, the real requirement provided by the
compact index API (recorded with VCR) was being ignored, and the
`Gemfile.lock` fake requirement was being used, which made the spec
pass. This is all expected, and to fix the issue I changed the spec to
be really realworld and don't fake any Bundler requirements.
https://github.com/rubygems/rubygems/commit/faf4ef46bc
The "dumb" terminal is considered only on MSys tty now. However, the
`TERM` feature has been used on many Unix-like systems for decades,
not MSys specific.
https://github.com/ruby/reline/commit/53fd51ab62
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
... 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
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
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>
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
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...
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
Do dependency filtering and materialization in one step. Before,
dependency filtering would not consider ruby metadata so it would
discard variants that end up not being materializable in the end.
https://github.com/rubygems/rubygems/commit/0c0d40d417
Co-authored-by: Ian Ker-Seymer <ian.kerseymer@shopify.com>
Not sure why, but I run into the following flaky test failure
````
(...)
Invoking `/Users/deivid/.asdf/installs/ruby/3.1.2/bin/ruby -I/Users/deivid/Code/rubygems/rubygems/bundler/spec -r/Users/deivid/Code/rubygems/rubygems/bundler/spec/support/artifice/fail.rb -r/Users/deivid/Code/rubygems/rubygems/bundler/spec/support/hax.rb /Users/deivid/Code/rubygems/rubygems/bundler/tmp/4/gems/system/bin/bundle install` failed with output:
----------------------------------------------------------------------
--- ERROR REPORT TEMPLATE -------------------------------------------------------
```
NameError: constant Pathname::FileUtils not defined
FileUtils.mkpath(@path, mode: mode)
^^^^^^^^^
/Users/deivid/.asdf/installs/ruby/3.1.2/lib/ruby/3.1.0/pathname.rb:585:in `mkpath'
/Users/deivid/Code/rubygems/rubygems/bundler/tmp/4/gems/system/gems/bundler-2.4.0.dev/lib/bundler/shared_helpers.rb:103:in `filesystem_access'
/Users/deivid/Code/rubygems/rubygems/bundler/tmp/4/gems/system/gems/bundler-2.4.0.dev/lib/bundler/rubygems_gem_installer.rb:78:in `build_extensions'
/Users/deivid/Code/rubygems/rubygems/bundler/tmp/4/gems/system/gems/bundler-2.4.0.dev/lib/bundler/rubygems_gem_installer.rb:28:in `install'
/Users/deivid/Code/rubygems/rubygems/bundler/tmp/4/gems/system/gems/bundler-2.4.0.dev/lib/bundler/source/rubygems.rb:207:in `install'
/Users/deivid/Code/rubygems/rubygems/bundler/tmp/4/gems/system/gems/bundler-2.4.0.dev/lib/bundler/installer/gem_installer.rb:54:in `install'
/Users/deivid/Code/rubygems/rubygems/bundler/tmp/4/gems/system/gems/bundler-2.4.0.dev/lib/bundler/installer/gem_installer.rb:16:in `install_from_spec'
/Users/deivid/Code/rubygems/rubygems/bundler/tmp/4/gems/system/gems/bundler-2.4.0.dev/lib/bundler/installer/parallel_installer.rb:186:in `do_install'
/Users/deivid/Code/rubygems/rubygems/bundler/tmp/4/gems/system/gems/bundler-2.4.0.dev/lib/bundler/installer/parallel_installer.rb:177:in `block in worker_pool'
/Users/deivid/Code/rubygems/rubygems/bundler/tmp/4/gems/system/gems/bundler-2.4.0.dev/lib/bundler/worker.rb:62:in `apply_func'
/Users/deivid/Code/rubygems/rubygems/bundler/tmp/4/gems/system/gems/bundler-2.4.0.dev/lib/bundler/worker.rb:57:in `block in process_queue'
/Users/deivid/Code/rubygems/rubygems/bundler/tmp/4/gems/system/gems/bundler-2.4.0.dev/lib/bundler/worker.rb:54:in `loop'
/Users/deivid/Code/rubygems/rubygems/bundler/tmp/4/gems/system/gems/bundler-2.4.0.dev/lib/bundler/worker.rb:54:in `process_queue'
/Users/deivid/Code/rubygems/rubygems/bundler/tmp/4/gems/system/gems/bundler-2.4.0.dev/lib/bundler/worker.rb:91:in `block (2 levels) in create_threads'
(...)
```
Whatever it was, this small change should fix it.
https://github.com/rubygems/rubygems/commit/71d7503ce4
This parameter was coupling the concept of lockfile with the index. I
don't think it's necessary.
Also I believe it's causing some flaky test failures, which might leak
into realworld issues. They are like this:
````
Invoking `/opt/hostedtoolcache/Ruby/3.0.4/x64/bin/ruby -I/home/runner/work/rubygems/rubygems/bundler/spec -r/home/runner/work/rubygems/rubygems/bundler/spec/support/artifice/fail.rb -r/home/runner/work/rubygems/rubygems/bundler/spec/support/hax.rb /home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/bin/bundle lock` failed with output:
----------------------------------------------------------------------
--- ERROR REPORT TEMPLATE -------------------------------------------------------
```
NoMethodError: undefined method `identifier' for #<Gem::Specification:0x00005639ad0db0a0 @extension_dir=nil, @full_gem_path=nil, @gem_dir=nil, @ignored=nil, @bin_dir=nil, @cache_dir=nil, @cache_file=nil, @doc_dir=nil, @ri_dir=nil, @spec_dir=nil, @spec_file=nil, @gems_dir=nil, @base_dir=nil, @loaded=false, @activated=false, @loaded_from=nil, @original_platform="ruby", @installed_by_version=nil, @autorequire=nil, @date=2022-07-25 00:00:00 UTC, @description="This is a completely fake gem, for testing purposes.", @email="foo@bar.baz", @homepage="http://example.com", @name="win32-process", @post_install_message=nil, @signing_key=nil, @summary="This is just a fake gem for testing", @version=#<Gem::Version "0.8.3">, @authors=["no one"], @bindir="bin", @cert_chain=[], @dependencies=[<Gem::Dependency type=:runtime name="ffi" requirements=">= 1.0.0">], @executables=[], @extensions=[], @extra_rdoc_files=[], @files=[], @licenses=[], @metadata={}, @platform="ruby", @rdoc_options=[], @require_paths=["lib"], @required_ruby_version=#<Gem::Requirement:0x00005639ad0dbc80 @requirements=[[">=", #<Gem::Version "0">]]>, @required_rubygems_version=#<Gem::Requirement:0x00005639ad0dba50 @requirements=[[">=", #<Gem::Version "0">]]>, @requirements=[], @rubygems_version="3.2.33", @specification_version=4, @test_files=[], @new_platform="ruby", @full_name="win32-process-0.8.3", @has_rdoc=true, @license=["MIT"] win32-process-0.8.3>
/home/runner/work/rubygems/rubygems/bundler/tmp/rubygems/lib/rubygems/specification.rb:2116:in `method_missing'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/remote_specification.rb:115:in `method_missing'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/lazy_specification.rb:34:in `eql?'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/index.rb:189:in `eql?'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/index.rb:189:in `search_by_dependency'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/index.rb:96:in `local_search'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/index.rb:64:in `unsorted_search'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/index.rb:60:in `search'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/resolver.rb:179:in `results_for'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/resolver.rb:113:in `search_for'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/resolver.rb:216:in `block in sort_dependencies'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/resolver.rb:207:in `each'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/resolver.rb:207:in `sort_by'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/resolver.rb:207:in `sort_dependencies'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/vendor/molinillo/lib/molinillo/delegates/specification_provider.rb:60:in `block in sort_dependencies'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/vendor/molinillo/lib/molinillo/delegates/specification_provider.rb:77:in `with_no_such_dependency_error_handling'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/vendor/molinillo/lib/molinillo/delegates/specification_provider.rb:59:in `sort_dependencies'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/vendor/molinillo/lib/molinillo/resolution.rb:754:in `push_state_for_requirements'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/vendor/molinillo/lib/molinillo/resolution.rb:744:in `require_nested_dependencies_for'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/vendor/molinillo/lib/molinillo/resolution.rb:727:in `activate_new_spec'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/vendor/molinillo/lib/molinillo/resolution.rb:684:in `attempt_to_activate'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/vendor/molinillo/lib/molinillo/resolution.rb:254:in `process_topmost_state'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/vendor/molinillo/lib/molinillo/resolution.rb:182:in `resolve'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/vendor/molinillo/lib/molinillo/resolver.rb:43:in `resolve'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/resolver.rb:50:in `start'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/resolver.rb:24:in `resolve'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/definition.rb:480:in `reresolve'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/definition.rb:283:in `resolve'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/definition.rb:181:in `resolve_remotely!'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/cli/lock.rb:53:in `run'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/cli.rb:674:in `lock'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/vendor/thor/lib/thor.rb:392:in `dispatch'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/cli.rb:31:in `dispatch'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/cli.rb:25:in `start'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/exe/bundle:48:in `block in <top (required)>'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/lib/bundler/friendly_errors.rb:120:in `with_friendly_errors'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/gems/bundler-2.4.0.dev/exe/bundle:36:in `<top (required)>'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/bin/bundle:23:in `load'
/home/runner/work/rubygems/rubygems/bundler/tmp/1/gems/system/bin/bundle:23:in `<main>'
```
````
I think the issue is that now we eagerly materialize some base
specifications before resolving in order to give better errors if user
specified an incorrect source in the Gemfile.
This means that the key for the index hash will have heterogeneous
specification objects (some LazySpecification, some real Specification),
and `LazySpecification#eql?` is incompatible with that.
By dropping the base parameter from the index, we should no longer have
these heterogenous objects as hash keys.
https://github.com/rubygems/rubygems/commit/dc179d41c3
"Pointer" is not what we usually use to describe a selected item.
"Highlight" is a more common word for the scenario so we should use it instead.
https://github.com/ruby/reline/commit/b4279d1557
Running a command like that is actually removing any previous default
bundler specs in the default RubyGems installation (outside of destdir).
It should instead only modify destdir.
https://github.com/rubygems/rubygems/commit/5ed275383c
Specifying multiple primary sources in top-level was deprecated in
Bundler 1.13.
As Bundler CLI uses primary source instead of global, "global source"
is replaced with "primary source".
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
Signed-off-by: Takuya Noguchi <takninnovationresearch@gmail.com>
https://github.com/rubygems/rubygems/commit/1dd1753f6e
deduplicate_call_seq has a bug that skips call-seq for methods where the
alias is a prefix of the method name. For example, if the alias name is
"each" and the current method name is "each_line", then
deduplicate_call_seq will skip all call-seq for "each_line" since it
will believe that it is for the alias.
https://github.com/ruby/rdoc/commit/1148988ccc
WASI doesn't guarantee that `/dev/null` is present.
So without this patch, we needed to mount host's `/dev` directory to WASI
guest process to avoid `ENOTCAPABLE` error while `require "bundler/setup"`
https://github.com/rubygems/rubygems/commit/e9187ab61f
As pointed out in the
[comment](https://github.com/ruby/reline/pull/413#issuecomment-1168033973),
the code is actually a control sequence and not only for colors.
To make the dialog color APIs safer to use, we should restrict its
usages and extract away the bg/fg concept from the input.
So in this commit, I made these changes:
1. The dialog_*_bg/fg_color APIs only takes and returns color names (symbol):
- :black
- :red
- :green
- :yellow
- :blue
- :magenta
- :cyan
- :white
2. Add additional dialog_*_bg/fg_color_sequence APIs to access the raw code.
https://github.com/ruby/reline/commit/b32a977766
example.org is used mirror URL as an example, not to make access to
a (potential) third-party domain.
Signed-off-by: Takuya Noguchi <takninnovationresearch@gmail.com>
https://github.com/rubygems/rubygems/commit/31230f850c
Previously if `~/.bundle/cache/compact_index/rubygems.org.*/version`
were owned by root with read-only access, `bundle install` would fail
with a misleading error message. For example:
```
There was an error while trying to write to `/tmp/bundler-compact-index-20220711-1823-npllre/versions`. It is
likely that you need to grant write permissions for that path.
```
This happened because the EACCESS error was caught by
`SharedHelpers.filesystem_access`, which makes it look like the target
directory is at fault instead of the source.
We can't simply drop this guard because that causes the opposite
problem: the permission error appears to come from the source instead of
the target, since `CompactIndexClient::Cache#lines` also wraps read
access errors.
Instead, bring a minimal implementation of `FileUtils.cp` and nest calls
to `SharedHelpers.filesystem_access` properly.
https://github.com/rubygems/rubygems/commit/320822c070
Co-authored-by: Stan Hu <stanhu@gmail.com>
Since a few commits ago, we no longer call `Gem::Specification.reset`
after each invocation of `Gem::Installer#install`. This means we don't
call it when the default Bundler is installed during `gem update
--system`. This causes no issues until the end of the upgrade process
when:
* The previous default Bundler spec is removed from disk.
* All specification stubs are turned into real specifications by loading
them from disk. But the one for Bundler no longer exists so
materializes to `nil` and regenerating binstubs crashes like this:
```
Bundler 2.4.0.dev installed
RubyGems 3.4.0.dev installed
Regenerating binstubs
ERROR: While executing gem ... (NoMethodError)
undefined method `platform' for nil:NilClass
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/commands/pristine_command.rb:116:in `block in execute'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/specification.rb:981:in `block in each'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/specification.rb:980:in `each'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/specification.rb:980:in `each'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/commands/pristine_command.rb:116:in `map'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/commands/pristine_command.rb:116:in `each'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/commands/pristine_command.rb:116:in `select'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/commands/pristine_command.rb:116:in `execute'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/command.rb:323:in `invoke_with_build_args'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/command.rb:301:in `invoke'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/commands/setup_command.rb:604:in `regenerate_binstubs'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/commands/setup_command.rb:183:in `execute'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/command.rb:323:in `invoke_with_build_args'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/command_manager.rb:185:in `process_args'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/command_manager.rb:149:in `run'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/gem_runner.rb:51:in `run'
setup.rb:33:in `<main>'
```
We fix it by more carefully managing the removal of the previous default
Bundler gem.
https://github.com/rubygems/rubygems/commit/9989f6d5af
Modifies RDoc to Emphasize keys instead of roots, values instead of objects.
Code:
Renames method #root? to #key? and method #roots to #keys.
Aliases method #key as #root and method #keys as #roots.
Adds testing for all four methods.
https://github.com/ruby/pstore/commit/4436ea0891
* Use colorable: argument as the only coloring control
* Centalize color controling logic at Color.colorable?
There are 2 requirements for coloring output:
1. It's supported on the platform
2. The user wants it: `IRB.conf[:USE_COLORIZE] == true`
Right now we check 1 and 2 separately whenever we colorize things.
But it's error-prone because while 1 is the default of `colorable`
parameter, 2 always need to manually checked. When 2 is overlooked, it
causes issues like https://github.com/ruby/irb/pull/362
And there's 0 case where we may want to colorize even when the user
disables it. So I think we should merge 2 into `Color.colorable?` so it
can be automatically picked up.
* Add tests for all inspect modes
* Simplify inspectors' coloring logic
* Replace use_colorize? with Color.colorable?
* Remove Context#use_colorize cause it's redundant
https://github.com/ruby/irb/commit/1c53023ac4
When running a command with the `--verbose` flag that ends up raising a
`BundlerError`, Bundler will unnecessarily print the error twice.
This commit fixes the issue by removing the duplicate logging.
https://github.com/rubygems/rubygems/commit/689004a164
When outputting a (possibly truncated) value, IRB will query the
window size. However, if IRB was piped to another process, stdout
will no longer be a TTY and will not support the `winsize` method.
This fix ensure that stdout is a TTY.
https://github.com/ruby/irb/commit/125de5eeea
While generate_index did clean up temporary directory, when running with
--update flag, that did not happen and the temporary directory was left
behind.
This commit fixes that and modifies tests in order to make sure this is
not reintroduced later on.
Fixes#5635.
https://github.com/rubygems/rubygems/commit/9fa34dc329
The paths for extensions of gems would contain the hardcoded ruby
version on which the extension was built. This will replace it with
runtime ruby version like the parent version directory. It will make the
standalone script compatible between different ruby version installations.
https://github.com/rubygems/rubygems/commit/a9dae93d5d
I was looking at (yet another) flamegraph in speedscope, and used the
'left hand heavy' and was shocked to realize that 0.5s of the 1.7s
is spent in DepProxy#name. This method _only_ delegates the name to an
underlying spec, so it's not complex at all.
It seems to be of how often this line ends up calling it:
next if handled.any?{|d| d.name == dep.name && (match_current_platform || d.__platform == dep.__platform) } || dep.name == "bundler"
The `handled` array is built up as dependencies are handled, so this get
slower as more dependencies are installed.
This change changes how `handled` is track. Instead of just an array, I've
tried using a Hash, with the key being a dep's name, and the value being
a list of deps with that name. This means it's constant time to find
the dependencies with the same name.
I saw a drop from 1.7s to 1.0s against master, and from 0.95s to 0.24s
when used with https://github.com/rubygems/rubygems/pull/5533https://github.com/rubygems/rubygems/commit/844dac30d4
* Added a nil check in Net::HTTPHeader#initialize_http_header for keys in the header that do not have any value
* Returning nil from the content_range method instead of raising an error when the unit in the content-range header is not bytes
* Modified initialize_http_header to match trunk
fix [Bug #11450]
fix https://github.com/ruby/ruby/pull/1018
It sent the char to check even to non-tty, e.g., pipe.
This causes `unknown command: "\xE2\x96\xBDstart ` warnings on
ruby's parallel test on Windows, where non-standard FDs cannot be
passed to child processes.
https://github.com/ruby/reline/commit/0d373647fb
These gemspecs already work most of the times. When they are installed
normally, the require_paths in the gemspec stub line becomes actually
correct, and the incorrect value in the real gemspec is ignored. It only
becomes an issue in standalone mode.
In Ruby 3.2, `Kernel#=~` has been removed, and that means that it
becomes harder for us to gracefully deal with this error in standalone
mode, because it now happens earlier due to calling `Array#=~` for this
invalid gemspec (since require_paths is incorrectly an array of arrays).
The easiest way to fix this is to actually make this just work instead
by automatically fixing the issue when reading the packaged gemspec.
https://github.com/rubygems/rubygems/commit/d3f2fe6d26
Previously we would instantiate two different packages and extract the
specification from the package twice for each gem installed. We can
reuse the installer for this so that we just need to do it once.
https://github.com/rubygems/rubygems/commit/e454f850b1
`timeout 0.3.0` broke our test suite because we have some
tests that stubs `Process.clock_gettime` making it return
a value in the past, causing `Timeout` to trigger almost immediately.
I beleive it wasn't a problem before because it was relying on `Process.sleep`.
https://github.com/ruby/timeout/commit/e5911a303e
Currently only literal `0` and `1` are accepted as `read`/`write`
flags.
This patch allows other boolean arguments, C macros (`FALSE`/`TRUE`),
Ruby `VALUE`s (`Qfalse`/`Qtrue`), and C99 `bool`s (`false`/`true`), as
well.
https://github.com/ruby/rdoc/commit/169dc02e3c
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
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
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 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
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
Apparently old versions of MacOS would set `GEM_HOME` to a `/System`
folder, and trying to create a file there raises `Errno::EROFS`.
We ignore the error. Any permission issues should be better handled
further down the line.
https://github.com/rubygems/rubygems/commit/ef90c071d0
This kind of error can happen when setting `GEM_HOME` to a path
under MacOS System Integrity Protection.
We ignore the error. Any permission issues should be better handled
further down the line.
https://github.com/rubygems/rubygems/commit/174cb66863
Instead of guessing on the culprit.
We actually have a helper, `Bundler.rm_rf`, with exactly the behavior
that we want:
* Allow the passed folder to not exist.
* No exception swallowing other than that.
https://github.com/rubygems/rubygems/commit/5fa3e6f04a
This maybe isn't probably isn't the best approach, but it will allow
`Fiddle::Terminfo.curses_dl` to work. I documented more details about
this in an issue on fiddle: https://github.com/ruby/fiddle/issues/107
It is probably better to deal with it there. But this is workaround is
simpler.
FYI: `reline` itself seems to be working just fine for me _without_
loading ncurses. But I wanted to be able to use `Reline::Terminfo` for
my own projects. :)
https://github.com/ruby/reline/commit/fd4bdb35e2
I am asking did_you_mean to use Exception#detailed_message to add
"Did you mean?" suggestion instead of overriding #message method.
https://github.com/ruby/did_you_mean/pull/177
Unfortunately, the change will affect Gem::UnknownCommandError, which
excepts did_you_mean to override #message method.
This PR absorbs the change of did_you_mean.
Gem::CommandManager now calls #detailed_message method to get a message
string with "Did you mean?" suggestion from an exception.
https://github.com/rubygems/rubygems/commit/8f104228d3
On a different patch, it was noticed Ngam Pham that we are calling
`LazySpecification#hash` many times, and simply memoizing that led to a
very considerable performance improvement in his app.
I noticed though that we shouldn't be calling `LazySpecification#hash`
that many times, and I located the culprit at `SpecSet#for` where we
were deduplicating the partial aggregated result on every iteration. It
is enough to do it just once at the end.
This leads on a 12% speedup on Rails repository Gemfile vs the previous
8% I was getting from memoizing `LazySpecification#hash`. Also, after
this patch memoizing `LazySpecification#hash` has no effect in
performance anymore.
https://github.com/rubygems/rubygems/commit/68d00a9edd
Co-authored-by: Ngan Pham <ngan@users.noreply.github.com>
Note this change is only for `configure.ac`, not for Windows using
`win32/configure.bat`.
```
$ ./configure --help | grep mkmf
--enable-mkmf-verbose enable verbose in mkmf
```
Run the following command to enable the mkmf verbose mode.
```
$ ./configure --enable-mkmf-verbose
$ grep MKMF_VERBOSE config.status
S["MKMF_VERBOSE"]="1"
```
In this mkmf verbose mode, when compiling a native extension, the
`rake compile` prints the compiling commands such as
"gcc -I. <...> path/to/file" instead of "compiling path/to/file".
```
$ git clone https://github.com/deivid-rodriguez/byebug.git
$ cd byebug
$ bundle install --standalone
$ bundle exec rake compile
...
gcc -I. <...> path/to/file
...
```
URI::Generic#{user,password} return the encoded values, which are
not that useful if you want to do authentication with them.
Automatic decoding by default would break backwards compatibility.
Optional automatic decoding via a keyword to URI.parse would
require threading the option through at least 3 other methods, and
would make semantics confusing (user= takes encoded or unencoded
password?) or require more work. Thus, adding this as a separate
method seemed the simplest approach.
Unfortunately, URI lacks a method for correct decoding. Unlike in
www form components, + in earlier parts of the URI such as the
userinfo section is treated verbatim and not as an encoded space.
Add URI.#{en,de}code_uri_component methods, which are almost the
same as URI.#{en,de}code_www_form_component, but without the
special SP => + handling.
Implements [Feature #9045]
https://github.com/ruby/uri/commit/16cfc4e92f
The module here is called `URI`, so it's probably reasonable to expect a requirement for the path to be RFC3986-compliant, but on the other hand, the class is called `File`, so it might be reasonable to expect that a path produced by e.g. the `File` class would be consumable by its `build` method (this fails if the filename contains e.g. a space).
https://github.com/ruby/uri/commit/ef79789b83
David Rodríguez
tompng
Jenny Shen
Jemma Issroff
Jeremy Evans
Mike Dalessio
Lars Kanis
Hiroshi SHIBATA
Aaron Patterson
Samuel Williams
Takashi Kokubun
Otávio Schwanck dos Santos
Takuya Noguchi
st0012
Nobuyoshi Nakada
Kevin Newton
rm155
Antonio Paulino
Imir Kiyamov
なつき
Mau Magnaguagno
Jean Boussier
shields
Aleksandr Varnin
Jun Aruga
Vít Ondruch
Yusuke Endoh
Loic Nageleisen
schneems
Burdette Lamar
Alan Wu
Yuta Saito
Ilya Dyakonov
Luka Dornhecker
konsolebox
moe
Peter Zhu
Ashley Ellis Pierce
Olle Jonsson
Brian Le
pocari
Peter Jones
Tomas Volf
citrusmoose
Josh Nichols
Shishir Joshi
Daniel Berger
Alexander Ilyin
Pavel Rosický
Ellen Marie Dash
nicholas a. evans
ima1zumi
Jean byroot Boussier
Benoit Daloze
Kouhei Yanagita
Kazuhiro NISHIYAMA
Frank Schmitt