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
Currently, auto-install with git gems fails, when
it would succeed with a rubygems-source gem
Fix the issue by doing the same fallback for git errors as we do for
missing gems, the git errors should only bubble up in these cases when
the gem is not installed, meaning we want to go through the install flow
(and any persistent errors will be raised through there)
https://github.com/rubygems/rubygems/commit/e25a339f7a
Fundamentally, `foo { |bar,| }` is different from `foo { |bar, *| }`
because of arity checks. This PR introduces a new node to handle
that, `ImplicitRestNode`, which goes in the `rest` slot of parameter
nodes instead of `RestParameterNode` instances.
This is also used in a couple of other places, namely:
* pattern matching: `foo in [bar,]`
* multi target: `for foo, in bar do end`
* multi write: `foo, = bar`
Now the only splat nodes with a `NULL` value are when you're
forwarding, as in: `def foo(*) = bar(*)`.
https://github.com/ruby/prism/commit/dba2a3b652
* Remove trailing spaces
* Migrate show_source tests to integration tests
Because show_source tests often need to define class and/or methods,
they can easily leak state to other tests. Changing them to integration
tests will ensure that they are run in a clean environment.
* Fix NoMethodError caused by SourceFinder#method_target
3c39f13397
prompt
(https://github.com/ruby/irb/pull/791)
Currently, IRB just terminates if `main.to_s` raises while IRB
constructs the prompt string. This can easily happen if the user wants
to start an IRB session in the instance scope of an uninitialized
object, for example:
```
class C
def initialize
binding.irb
@values = []
end
def to_s = @values.join(',') # raises if uninitialized
end
C.new
```
This patch makes IRB rescue from such an exception and displays the
class name of the exception instead of `main.to_s` to indicate some
error has occurred.
We may display more detailed information about the exception, but this
patch chooses not to do so because 1) the prompt has limited space,
2) users can evaluate `to_s` in IRB to examine the error if they want,
and 3) obtaining the details can also raise, which requires nested
exception handling and can be complicated.
https://github.com/ruby/irb/commit/412ab26067
This changes the CompactIndexClient to store etags received from the
compact index in separate files rather than relying on the MD5 checksum
of the file as the etag.
Smoothes the upgrade from md5 etags to opaque by generating them when no
etag file exists. This should reduce the initial impact of changing the
caching behavior by reducing cache misses when the MD5 etag is the same.
Eventually, the MD5 behavior should be retired and the etag should be
considered completely opaque with no assumption that MD5 would match.
```
==> memprof.after.txt <==
Total allocated: 1.13 MB (2352 objects)
Total retained: 10.08 kB (78 objects)
==> memprof.before.txt <==
Total allocated: 46.27 MB (38439 objects)
Total retained: 9.94 kB (75 objects)
```
Yes, we were allocating 45MB of arrays in `dependencies_installed?`,
it was accidentally cubic.
https://github.com/rubygems/rubygems/commit/13ab874388
If truncation is detected, return immediately from decode so that
the UDP connection can be retried with TCP, instead of failing to
decode due to trying to decode a truncated response.
Fixes [Bug #13513]
https://github.com/ruby/resolv/commit/0de996dbca
(https://github.com/ruby/resolv/pull/33)
* Implement dohpath SvcParam [RFC 9461]
This patch implements "dohpath" SvcParam proposed in
[draft-ietf-add-svcb-dns-08]. This parameter specifies a URI template
for the :path used in DNS-over-HTTPS requests.
"dohpath" is employed by [DDR], also a to-be-published Proposed Standard
that specifies how to upgrade DNS transport to a more secure one, i.d.,
DNS-over-TLS or DNS-over-HTTPS. DDR is deployed in the public DNS
resolvers including Cloudflare DNS, Google Public DNS, and Quad9.
[RFC 9461]: https://datatracker.ietf.org/doc/rfc9461/
[DDR]: https://datatracker.ietf.org/doc/draft-ietf-add-ddr/https://github.com/ruby/resolv/commit/da9c023539
Co-authored-by: Sorah Fukumori <her@sorah.jp>
(https://github.com/ruby/resolv/pull/32)
* Add MessageDecoder#get_list
This method repeats yielding until all the data upto the current limit
is consumed, and then returns an Array containig the block results.
* Implement SVCB and HTTPS RRs [RFC 9460]
> This patch implements SVCB and HTTPS resource record types defined in
> [RFC 9460].
>
> The RR types are now supported by many server implementations including
> BIND, unbound, PowerDNS, and Knot DNS. Major browsers such as Chrome,
> Edge, and Safari have started to query HTTPS records, with the records
> gradually adopted by websites. Also, SVCB is actually deployed in the
> public DNS resolvers such as Cloudflare DNS and Google Public DNS for
> [DDR].
>
> With such wide adoption, we have plenty of real-world use cases, and
> it is unlikely the wire format will change further in an incompatible
> way. It is time to implement them in the client libraries!
>
> # Rationale for proposed API
>
> ## `Resolv::DNS::Resource::IN::ServiceBinding`
>
> This is an abstract class for SVCB-compatible RR types.
> SVCB-compatible RR types, as defined in the Draft, shares the wire
> format and the semantics of their RDATA fields with SVCB to allow
> implementations to share the processing of these RR types. So we do
> so.
>
> The interface of this class is straightforward: It has three
> attributes `priority`, `target`, and `params`, which correspond the
> RDATA fields SvcPriority, TargetName, and SvcParams, resp.
>
> SVCB RR type is defined specifically within IN class. Thus, this
> class is placed in the `Resolv::DNS::Resource::IN` namespace.
>
> ## `Resolv::DNS::Resource::IN::SVCB`, `Resolv::DNS::Resource::IN::HTTPS`
>
> Just inherits ServiceBinding class.
>
> ## `Resolv::DNS::SvcParam`
>
> This class represents a pair of a SvcParamKey and a SvcParamValue.
> Aligned with the design of `Resolv::DNS::Resource`, each SvcParamKey
> has its own subclass of `Resolv::DNS::SvcParam`.
>
> ## `Resolv::DNS::SvcParam::Generic`
>
> This is an abstract class representing a SvcParamKey that is unknown
> to this library. `Generic.create(key)` dynamically defines its
> subclass for specific `key`. E.g., `Generic.create(667)` will define
> `Generic::Key667`.
>
> This class holds SvcParamValue in its wire format.
>
> SvcParam with an unknown SvcParamKey will be decoded as a subclass of
> this class. Also, users of this library can generate a non-supported
> SvcParam if they know its wire format.
>
> ## `Resolv::DNS::SvcParams`
>
> This is conceptually a set of `SvcParam`s, whose elements have the
> unique SvcParamKeys. It behaves like a set, and for convenience
> provides indexing by SvcParamKey.
>
> - `#initialize(params)` takes an Enumerable of `SvcParam`s as the
> initial content. If it contains `SvcParam`s with the duplicate key,
> the one that appears last takes precedence.
> - `#[](key)` fetches the `SvcParam` with the given key. The key can be
> specified by its name (e.g., `:alpn`) or number (e.g., `1`).
> - `#add(param)` adds a `SvcParam` to the set. If the set already has a
> `SvcParam` with the same key, it will be replaced.
> - `#delete(key)` deletes a `SvcParam` by its key and returns it. The key
> can be specified by its name or number.
* Update comments referring to draft-ietf-dnsop-svcb-https-12
Published as RFC 9460. https://datatracker.ietf.org/doc/rfc9460/
[draft-ietf-dnsop-svcb-https-12]: https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/12/
[RFC 9460]: https://datatracker.ietf.org/doc/rfc9460/
[DDR]: https://datatracker.ietf.org/doc/draft-ietf-add-ddr/https://github.com/ruby/resolv/commit/b3ced7f039
(https://github.com/ruby/irb/pull/768)
When user enters irb:rdbg session, they don't get the same hint that the
`debug` gem provides, like
```
(rdbg) n # next command
```
This means that users may accidentally execute commands when they want to
retrieve the value of a variable.
So this commit adds a Reline output modifier to add a simiar hint:
```
irb:rdbg(main):002> n # debug command
```
It is not exactly the same as `debug`'s because in this case the importance
is to help users distinguish between value evaluation and debugger command
execution.
https://github.com/ruby/irb/commit/fdf24de851
If a platform specific variant would not match the current Ruby, we would still be
considering it compatible with the initial resolution and adding its
platform to the lockfile, but we would later fail to materialize it for
installation due to not really being compatible.
Fix is to only add platforms for variants that are also compatible with
current Ruby and RubyGems versions.
https://github.com/rubygems/rubygems/commit/75d1290843
* The same order as in source code.
* CallOrWriteNode, CallOperatorWriteNode, CallAndWriteNode already have
the correct order so it was also inconsistent with them.
https://github.com/ruby/prism/commit/4434e4bc22
(https://github.com/ruby/resolv/pull/25)
* IPv6: update to_s method to be RFC5952 compliant
I noticed that the resolv library does not honour RFC 5952 Section 4.2.2.
in relation to textural representation of ipv6 addresses:
The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field.
For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but
2001:db8::1:1:1:1:1 is not correct.
Fixes https://github.com/ruby/resolv/pull/24https://github.com/ruby/resolv/commit/5efcd6ed70
Co-authored-by: Sorah Fukumori <sora134@gmail.com>
(https://github.com/ruby/irb/pull/771)
I propose introducing the capability to set the IRB completion kinds via an environment variable, specifically `IRB_COMPLETOR=type`.
This feature aims to enhance the Rails console experience by allowing Rails users to specify their preferred completion more conveniently.
Currently, when using the Rails console, there's no straightforward way to globally set the type completion across a Rails application repository.
It's possible to configure this setting by placing a `.irbrc` file at the project root. However, using a .irbrc file is not ideal as it allows for broad configurations and can potentially affect the production environment.
My suggestion focuses on allowing users to set the completion to 'type' in a minimal.
This enhancement would be particularly beneficial for teams writing RBS in their Rails applications.
This type completer, integrated with RBS, would enhance completion accuracy, improving the Rails console experience.
https://github.com/ruby/irb/commit/032f6da25f
Calling `tokens_to_s` gets an error if `token_stream` is nil:
```
undefined method `compact' for nil:NilClass (NoMethodError)
```
So, fall back to an empty array if `@token_stream` is nil.
https://github.com/ruby/rdoc/commit/452e4a2600
Gem::RemoteFetcher uses Gem::Request, which adds the RubyGems UA.
Gem::RemoteFetcher is used to download gems, as well as the full index.
We would like the bundler UA to be used whenever bundler is making
requests.
This PR also avoids unsafely mutating the headers hash on the shared
`Gem::RemoteFetcher.fetcher` instance, which could cause corruption or
incorrect headers when making parallel requests. Instead, we create one
remote fetcher per rubygems remote, which is similar to the connection
segregation bundler is already doing
https://github.com/rubygems/rubygems/commit/f0e8dacdec
librubyparser was an artifact of the prototype that was initially
named ruby-parser. Instead, this renames it to libprism to be
consistent with the actual name.
https://github.com/ruby/prism/commit/8600b06811
If a Gemfile duplicates a development dependency also defined in a local
gemspec with a different requirement, the requirement in the local
gemspec will be silently ignored.
This surprised me.
I think we should either:
* Make sure both requirements are considered, like it happens for
runtime dependencies (I added a spec to illustrate the current behavior
here).
* Add a warning that the requirement in the gemspec will be ignored.
I think the former is slightly preferable, but it may cause some
bundle's that previously resolve to no longer resolver.
I went with the latter but the more I think about it, the more this
seems like it should behave like the former.
https://github.com/rubygems/rubygems/commit/ad6843972f