... instead of exact matching. I'm now creating a built-in gem that
modifies Exception's error message, so the expectation value is changed.
IMO, it is good to check that did_you_mean suggestion is NOT added in
the uncorrectable case.
ebe88ec4d2
Previously, did_you_mean used `msg.end_with?(suggestion)` to check if
its suggestion is already added.
I'm now creating a gem that also modifies Exception's message. This
breaks did_you_mean's duplication check.
This change makes the check use String#include? instead of end_with?.
b35e030549
Previously, DidYouMean::Correctable#original_message did
`method(:to_s).super_method.call` to call the original to_s method by
skipping Correctable#to_s.
I'm now creating a gem that prepends another to_s method to NameError,
which confuses the hack. An immediate solution is to replace it with
`method(:to_s).super_method.super_method.call` to skip the two methods.
But it is too ad-hoc.
This changeset uses more extensible approach and allow a prepended
module to declare that they should be skipped by defining a constant
named `SKIP_TO_S_FOR_SUPER_LOOKUP`.
8352c154e3
https://github.com/ruby/irb/pull/249 actually slowed down how `code` is
concatenated. The original way of creating `code` is faster.
[before]
user system total real
2.420137 0.005364 2.425501 ( 2.426264)
[after]
user system total real
1.000221 0.007454 1.007675 ( 1.008295)
Theoretically, this implementation might skip lines that don't appear in
Ripper tokens, but this assumes such lines don't impact whether the code
passes compilation or not. At least normal blank lines seem to have an
`on_ignored_nl` token anyway though.
27dd2867cd
When using a non-ASCII compatible source and destination encoding
and xml escaping (the :xml option to String#encode), the resulting
string was broken, as it used the correct non-ASCII compatible
encoding, but contained data that was ASCII-compatible instead of
compatible with the string's encoding.
Work around this issue by detecting the case where both the
source and destination encoding are non-ASCII compatible, and
transcoding the source string from the non-ASCII compatible
encoding to UTF-8. The xml escaping code will correctly handle
the UTF-8 source string and the return the correctly encoded
and escaped value.
Fixes [Bug #12052]
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
This broke coverage CI
```
1) Failure:
TestRequire#test_load_syntax_error [/home/runner/work/actions/actions/ruby/test/ruby/test_require.rb:228]:
Exception(SyntaxError) with message matches to /unexpected/.
[SyntaxError] exception expected, not #<TypeError: no implicit conversion of false into Integer>.
```
2914743968
For ruby/ruby repository's AppVeyor CI (Windows environment), `Reline::IOGate.encoding` will be changed from `UTF-8` to `Windows-31J` after the test is run.
So, when `test/reline/test_key_actor_emacs.rb` is loaded, `Reline::IOGate.encoding == Encoding::UTF_8` will be `true`,
but at the time of test execution, `Reline::IOGate.encoding` is `Windows-31J`.
For this reason, I changed the test method to check `Reline::IOGate.encoding` in the test method.
10e1ce3320
It is unclear why this was implemented, I assume
it was for performance back in 2006.
However today, this compression defeats bytecode caching
entirely and end up being counter productive.
ae3703c1d0
This was already documented as being ignored, but it wasn't being
ignored, causing an issue in a particular case where a UTF-8
pattern was provided and a filename was tested that wasn't valid
UTF-8.
Fixes [Bug #14456]
If the type is ADJUST we don't want to treat it like an INSN so we have
to check the type before reading from `insn_info.events`.
[Bug #18001] [ruby-core:104371]
Co-authored-by: Aaron Patterson <tenderlove@ruby-lang.org>
