comptime_key is a Ruby object and the value is not valid in machine code.
This PR also implements `CMP r/m64, imm32 (Mod 01: [reg]+disp8)` that is
now needed for running mail.gem benchmark.
(https://github.com/ruby/irb/pull/817)
1. Because `IRB.rc_file` always generates an rc file name, even if the
file doesn't exist, we should check the file exists before trying to
load it.
2. If any type of errors occur while loading the rc file, we should
warn the user about it.
https://github.com/ruby/irb/commit/37ffdc6b19
Refactor vendoring to allow validating vendoring is reproducible
Helps ensure that unsuspecting diffs to the vendored code arent accidentally introduced
Previous attempt to use a full path when the running version is
different than the one that would be activated by default are different
was not correct.
This is because if this error happens in a `bundle exec` context, the
`Gem.loaded_specs` is cleared because we're in an exec'd process, so
will be always using a full path in these cases.
This alternative approach should do what I was expecting.
https://github.com/rubygems/rubygems/commit/e0bb8bf51b
It's the `Gem::Installer` below what installs executables, and the code
being deleted here is now actually creating a `gems/` folder in the root
of the source repo when running `ruby setup.rb`.
https://github.com/rubygems/rubygems/commit/0e69a8b0d6
For Ruby re-distributors, automatic user-install might be the right
default. Therefore printing warning about installing into user directory
is not always desirable. Let the default_user_install method be
customizable.
https://github.com/rubygems/rubygems/commit/2320dba544
This problem is quite specific to our dev environment, but I guess the
fix could be handy for other situations.
After merging a change to treat default gems as regular gems, I get this
when trying to run `rubocop` on our repo:
```
$ bin/rubocop --only Performance/RegexpMatch
Could not find json-2.6.3 in locally installed gems
Run `bundle install --gemfile /Users/deivid/code/rubygems/rubygems/tool/bundler/lint_gems.rb` to install missing gems.
```
However, when running the suggested command, nothing changes and I still
get the same error:
```
$ bundle install --gemfile /Users/deivid/code/rubygems/rubygems/tool/bundler/lint_gems.rb
Using ast 2.4.2
Using bundler 2.4.10
Using json 2.6.3
Using parallel 1.23.0
Using racc 1.7.1
Using parser 3.2.2.3
Using rainbow 3.1.1
Using regexp_parser 2.8.1
Using rexml 3.2.5
Using rubocop-ast 1.29.0
Using ruby-progressbar 1.13.0
Using unicode-display_width 2.4.2
Using rubocop 1.52.1
Using rubocop-performance 1.14.2
Bundle complete! 2 Gemfile dependencies, 14 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
$ bin/rubocop --only Performance/RegexpMatch
Could not find json-2.6.3 in locally installed gems
Run `bundle install --gemfile /Users/deivid/code/rubygems/rubygems/tool/bundler/lint_gems.rb` to install missing gems.
```
The problem is that our `bin/rubocop` script uses the development
version of Bundler (which has the change causing the problem), but the
advice recommands the default version of Bundler, which does not yet
have the change.
This commit changes the advice to recommend to use the same version of
Bundler that run into the problem in the first place.
So in the above situation you now get:
```
$ bin/rubocop --only Performance/RegexpMatch
Could not find json-2.6.3 in locally installed gems
Run `/Users/deivid/code/rubygems/rubygems/bundler/exe/bundle install --gemfile /Users/deivid/code/rubygems/rubygems/tool/bundler/lint_gems.rb` to install missing gems.
```
And running that fixes the problem:
```
$ /Users/deivid//rubygems/rubygems/bundler/exe/bundle install --gemfile /Users/deivid/code/rubygems/rubygems/tool/bundler/lint_gems.rb
Fetching gem metadata from https://rubygems.org/.........
Fetching json 2.6.3
Installing json 2.6.3 with native extensions
Bundle complete! 2 Gemfile dependencies, 14 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
```
https://github.com/rubygems/rubygems/commit/10a9588c6d
If a gem is specified in the Gemfile (or resolved as a transitive
dependency), it's always resolved from remote/installed sources. Default
gems are only used as a fallback for gems not included in the bundle.
I believe this leads to more consistent behavior and more portable apps,
since all gems will be installed to the configured bundle path,
regardless of whether they are default gems or not.
https://github.com/rubygems/rubygems/commit/091b4fcf2b
This makes bundler consistent with all other gems, and makes the default
installation of Bundler in the release package look like any other
bundler installation.
Before (on preview3, for example), Bundler executable is installed at:
lib/ruby/gems/3.3.0+0/gems/bundler-2.5.0.dev/libexec/bundle
Now it's installed in the standard location:
lib/ruby/gems/3.3.0+0/gems/bundler-2.5.0.dev/exe/bundle
The `options[:user_install]` might have three states:
* `true`: `--user-install`
* `false`: `--no-user-install` and
* `nil`: option was not specified
However, this had not been respected previously and the `false` and `nil`
were treated the same. This could lead to auto user installation despite
`--no-user-install` being specified on the command line.
Fixes https://github.com/rubygems/rubygems/pull/7237https://github.com/rubygems/rubygems/commit/9281545474
I think we can safely assume these days that all RubyGems and Bundler
versions that will ever bundle a new gem created in 2023 support
prereleases.
So this non transparent requirement is not necessary.
In my opinion, it should be the gem author to explicitly add this
constraint, not RubyGems.
https://github.com/rubygems/rubygems/commit/b165e6d725
For now, on a small rails app I have hanging around:
```
==> memprof.after.txt <==
Total allocated: 872.51 MB (465330 objects)
Total retained: 40.48 kB (326 objects)
==> memprof.before.txt <==
Total allocated: 890.79 MB (1494026 objects)
Total retained: 40.40 kB (328 objects)
```
Not a huge difference in memory usage, but it's a drastic improvement
in total number of allocations.
Additionally, this will pay huge dividends once
https://github.com/ruby/zlib/pull/61 is merged, as it will allow us to
completely avoid allocations in the repeated calls to readpartial,
which currently accounts for most of the memory usage shown above.
https://github.com/rubygems/rubygems/commit/f78d45d927
Uses Open3.popen2e in place of Open3.capture2e in Gem::Ext::Builder.
This change aims to stream stdout/stderr of ext builds when in verbose
mode, instead of printing everything at once when the build completes.
Nice for debugging gem builds that consumes longer times.
https://github.com/rubygems/rubygems/commit/dcdcb5adda
Before, when requiring "bigdecimal/math" in a Bundler context:
> /Users/deivid/.asdf/installs/ruby/3.3.0-dev/lib/ruby/3.3.0+0/bigdecimal/math.rb:2: warning: bigdecimal was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add bigdecimal to your Gemfile or gemspec.
After:
> foo.rb:1: warning: bigdecimal/math is found in bigdecimal, which will no longer be part of the default gems since Ruby 3.4.0. Add bigdecimal to your Gemfile or gemspec.
Before, when requiring "bigdecimal" in a Bundler context:
> foo.rb:1: warning: bigdecimal which will no longer be part of the default gems since Ruby 3.4.0. Add bigdecimal to your Gemfile or gemspec.
After:
> foo.rb:1: warning: bigdecimal was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add bigdecimal to your Gemfile or gemspec.
So generate_index can be implemented with dependencies, such as the compact index
Took this approach from feedback in https://github.com/rubygems/rubygems/pull/6853
Running `gem generate_index` by default will use an installed rubygems-generate_index, or install and then use the command from the gem
Apply suggestions from code review
https://github.com/rubygems/rubygems/commit/fc1cb9bc9e
Co-authored-by: Hiroshi SHIBATA <hsbt@ruby-lang.org>
Replace use of `STDIN`, `STDOUT` and `STDERR` constants by their
`$stdin`, `$stdout` and `$stderr` global variable equivalents.
This enables easier testing via standard means, such as `assert_output`
for minitest or `expect { print 'foo' }.to output.to_stdout` for RSpec
test suites.
https://github.com/rubygems/rubygems/commit/a0a6fc1b76
Additionally, the result is memoized, as it's used twice in a row.
This change does result in a net behavioral diff, as the list of ENVs
being checked has been updated (now includes buildkite, taskcluster,
cirrus, dsari, and drops buildbox and snap)
https://github.com/rubygems/rubygems/commit/3fb445a5a1
Because bundler needs to support older versions of rubygems, we can't
actually rely on Gem::CIDetector (yet - in a year or so they might be
able to consolidate, if they don't change futher). So we're copying it
into the Bundler:: namespace, and enforcing that they stay completely in
sync with a test. No other tests are needed, since Gem::CIDetector is
already tested, and this is and will remain identical.
https://github.com/rubygems/rubygems/commit/abc67f0da1
This is based on the list in Gem::UpdateSuggestion and Bundler::Fetcher;
these have similar purposes (determining whether/what CI we're executing
in), and can benefit from being combined and updated (they're both
slightly out of date).
Noteable changes:
* We'll consider ourselves to be on a CI in more cases - if CI_NAME or
TASKCLUSTER_ROOT_URL are set specifically, since those represent two
cases that were either overlooked or are no longer covered by the
existing implementation. (Or possibly TaskCluster still does provide
RUN_ID, but failed to document it)
* We will notice/track a few additional services in ci_strings (cirrus,
dsari, taskcluster), stop tracking 'snap' (they went under in 2017),
and update buildbox to buildkite (they've been called that for 8
years, and the BUILDBOX envs have been deprecated for 3).
* We'll also sort/uniq/downcase the values (all of which only matter
because of the special case of CI_NAME).
https://github.com/rubygems/rubygems/commit/60652b942f
Looks for the CHECKSUMS section in the lockfile, activating the feature
only if the section exists. Without a CHECKSUMS section, Bundler will
continue as normal, validating checksums when gems are installed while
checksums from the compact index are present.
https://github.com/rubygems/rubygems/commit/2353cc93a4
Before:
```
Expected a newline or semicolon after the statement
Cannot parse the expression
Expected a newline or semicolon after the statement
Cannot parse the expression
1 describe "webmock tests" do
22 it "body" do
27 query = Cutlass::FunctionQuery.new(
> 28 port: port
> 29 body: body
30 ).call
34 end
35 end
```
After:
```
Expected a newline or semicolon after the statement
Cannot parse the expression
1 describe "webmock tests" do
22 it "body" do
27 query = Cutlass::FunctionQuery.new(
> 28 port: port
> 29 body: body
30 ).call
34 end
35 end
```
https://github.com/ruby/syntax_suggest/commit/becf097e5e
Prism will be the parser in Ruby 3.3. We need to support 3.0+ so we will have to "dual boot" both parsers.
Todo:
- LexAll to support Prism lex output
- Add tests that exercise both Ripper and prism codepaths on CI
- Handle https://github.com/ruby/prism/issues/1972 in `ripper_errors.rb`
- Update docs to not mention Ripper explicitly
- Consider different/cleaner APIs for separating out Ripper and Prism
https://github.com/ruby/syntax_suggest/commit/a7d6991cc4
Previously only unknown word `intern` is allowed between a single-word
token before a C method. Now any single-word token, such as `inline`
which is used for `ArithmeticSequence` in enumerator.c, is allowed
instead.
https://github.com/ruby/rdoc/commit/3a214c1dd1
(https://github.com/ruby/irb/pull/761)
* Implement `history` command
Lists IRB input history with indices. Also aliased as `hist`.
* Add tests for `history` command
* Address feedback: `puts` with multiple arguments instead of `join`ing
* Address feedback: Handle nil from splitting an empty input string
* Refactor line truncation
* Add `-g` grep option to `history` command
* Add `history` command to README
* Remove unused `*args` parameter
* Allow spaces to be included in grep
* Allow `/` to be included in grep regex
* Handle `input` being an empty string
* Exclude "#{index}: " from matching the grep regex
* Add new line after joining
https://github.com/ruby/irb/commit/3f9eacbfa9
A lot of tools use Ripper/RubyVM::AbstractSyntaxTree to determine
if a source is valid. These tools both create an AST instead of
providing an API that will return a boolean only.
This new API only creates the C structs, but doesn't bother
reifying them into Ruby/the serialization API. Instead it only
returns true/false, which is significantly more efficient.
https://github.com/ruby/prism/commit/7014740118
Generally the removed message is very similar, but often it needs to
specify that the feature has "been removed" instead of "will be
removed", or "been deprecated". And a few chunks of text needed more
substantial updates. And a number of them seemed to have been carefully
crafted to make sense in either context, so I left those alone.
https://github.com/rubygems/rubygems/commit/8d42cf9104
Previously numbered parameters were a field on blocks and lambdas
that indicated the maximum number of numbered parameters in either
the block or lambda, respectively. However they also had a
parameters field that would always be nil in these cases.
This changes it so that we introduce a NumberedParametersNode that
goes in place of parameters, which has a single uint8_t maximum
field on it. That field contains the maximum numbered parameter in
either the block or lambda.
As a part of the PR, I'm introducing a new UInt8Field type that
can be used on nodes, which is just to make it a little more
explicit what the maximum values can be (the maximum is actually 9,
since it only goes up to _9). Plus we can do a couple of nice
things in serialization like just read a single byte.
https://github.com/ruby/prism/commit/2d87303903