SplatNodes within ArrayNodes (e.g. [*1..2, 3]) need to be special
cased in the compiler because they use a combination of concatarray
and newarray instructions to treat each sequence of splat or non-splat
elements as independent arrays which get concatenated. This commit
implements those cases.
This entirely changes how it is tested. Rather than to use counters
we now record the timeline of events with associated threads which
makes it much easier to assert that certains events are only preceded
by a specific event, and makes it much easier to debug unexpected
timelines.
Co-Authored-By: Étienne Barrié <etienne.barrie@gmail.com>
Co-Authored-By: JP Camara <jp@jpcamara.com>
Co-Authored-By: John Hawthorn <john@hawthorn.email>
There have been some sproradically flaky tests related to GC compaction,
which fail with:
1) Failure:
TestGCCompact#test_moving_hashes_down_size_pools [/test/ruby/test_gc_compact.rb:442]:
Expected 499 to be >= 500.
What's happening here, is that, _sometimes_, depending on very unlucky
combinations of machine things, one of the expected-to-be-moved hashes
might be found on the machine stack during GC, and thus pinned.
One factor which seems to make this _more_ likely is that GCC 11 on
Ubuntu 22.04 seems to want to allocate 440 bytes of stack space for
`gc_start`, which is much more than it actually uses on the common code
path. The result is that there are some 50-odd VALUE-sized cells "live"
on the stack which may well contain valid heap pointers from previous
function calls, and will need to be pinned.
This is, of course, totally normal and expected; Ruby's GC is
conservative and if there is the possibility that a VALUE might be live
on the machine stack, it can't be moved. However, it does make these
tests flaky.
This commit "fixes" the tests by performing the work in a fiber; the
fiber goes out of scope and should be collected by the call to
verify_compaction_references, so there should be no references to the
to-be-moved objects floating around on the machine stack.
Fixes [#20021]
(https://github.com/ruby/irb/pull/789)
If `output_modifier_proc`'s `complete` arg is true, it means the input is
submitted. In that case, debugger hint doesn't provide value to users
and adds noise to the output. So we hide it in such case.
f86d9dbe2f
(https://github.com/ruby/irb/pull/788)
Similar to Pry, it displays user-defined aliases in the help message with
a dedicated section. With the current default aliases, it looks like:
```
...other sections...
Aliases
$ Alias for `show_source`
@ Alias for `whereami`
```
2a0eacc891
(https://github.com/ruby/irb/pull/783)
With either `IRB.conf[:USE_PAGER] = false` or `--no-pager` commnad line flag.
I decided use `--no-pager` instead of `--use-pager` because it matches with
Pry and git's command line flags.
df1c3b9042
- Unless `sizeof(BDIGIT) == 4`, (8-byte integer not available), the
size to be loaded was wrong.
- Since `BDIGIT`s are dumped as raw binary, the loaded byte order was
inverted unless little-endian.
We use dh2048_ffdhe2048.pem file (DH 2048 bits) instead of dh1024.pem file in
both non-FIPS and FIPS cases. Because the following command fails to generate
the pem file with 1024 bits. And the OpenSSL FIPS 140-2 security policy
document explains the DH public keys are allowed from 2048 bits.[1]
```
$ OPENSSL_CONF=/home/jaruga/.local/openssl-3.3.0-dev-fips-debug-1aa08644ec/ssl/openssl_fips.cnf \
/home/jaruga/.local/openssl-3.3.0-dev-fips-debug-1aa08644ec/bin/openssl \
dhparam -out dh1024.pem 1024
Generating DH parameters, 1024 bit long safe prime
dhparam: Generating DH key parameters failed
```
The dh2048_ffdhe2048.pem file was created by the following command with the
OpenSSL FIPS configuration file. The logic to generate the DH pem file is
different between non-FIPS and FIPS cases. In FIPS, it seems that the command
always returns the text defined as ffdhe2048 in the FFDHE groups in RFC 7919
unlike non-FIPS.[2]
As the generated pem file is a normal and valid PKCS#3-style group parameter, we
use the file for the non-FIPS case too.
```
$ OPENSSL_CONF=/home/jaruga/.local/openssl-3.3.0-dev-fips-debug-1aa08644ec/ssl/openssl_fips.cnf \
/home/jaruga/.local/openssl-3.3.0-dev-fips-debug-1aa08644ec/bin/openssl \
dhparam -out dh2048_ffdhe2048.pem 2048
```
Note that the hard-coded PEM-encoded string in the `test_DHparams` is
intentional to avoid modifying the content unintentionally.
* [1] https://www.openssl.org/source/ - OpenSSL 3.0.8 FIPS 140-2 security
policy document page 25, Table 10 – Public Keys - DH Public
- DH (2048/3072/4096/6144/8192) public key agreement key
* [2] RFC7919 - Appendix A.1: ffdhe2048
https://www.rfc-editor.org/rfc/rfc7919#appendix-A.1
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]
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/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/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.
fdf24de851
(https://github.com/ruby/prism/pull/1906)
* Add test for KOI8-U
* Rename koi8 char_width function
- Rename function for use with any KOI8-based encoding
* Add KOI8-U encoding
* Add encoding to encoding.md
6cad4552f7
* The same order as in source code.
* CallOrWriteNode, CallOperatorWriteNode, CallAndWriteNode already have
the correct order so it was also inconsistent with them.
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/245efcd6ed70
Co-authored-by: Sorah Fukumori <sora134@gmail.com>
Many tests start by exhausting all shapes, which is a slow process.
By exposing a method to directly move the bump allocator forward
we cut test runtime in half.
Before:
```
Finished tests in 1.544756s
```
After:
```
Finished tests in 0.759733s,
```
constant
(https://github.com/ruby/prism/pull/1742)
* Raise if constant path parts contains nodes that can't be used to build full name
* Fix typo in constant path error documentation
Co-authored-by: Tim Morgan <tim@timmorgan.org>
---------
d73a053262
Co-authored-by: Tim Morgan <tim@timmorgan.org>
Right now when you have a lot of string concats it ends up being
difficult to work with because of the depth of the tree. You end
up descending very far for every string literal that is part of the
concat.
There are already times when we use an interpolated string node to
group together two string segments that are part of the same string
(like when they are interupted by the contents of a heredoc). This
commit takes the same approach and replaces string concats with
interpolated string nodes.
Now that they're a flat list, they should be much easier to work
with. There's still some missing information here that would be
useful to consumers: whether or not there is _actually_ any
interpolation contained in the list. We could remedy this with
another node type that is named something like string list, or we
could add a flag to interpolated string node indicating that there
is interpolation. Either way I want to solve that in a follow-up
commit, since this commit is valuable on its own.
1e7ae3ad1b
The lookup in the table is using the wrong key when converting generic
instance variables to too complex, which means that it never looks up
the entry which leaks memory when the entry is overwritten.
