This prevents early collection of the array. The GC doesn't see the
array on the stack when Ruby is compiled with optimizations enabled
[ruby-core:105099] [Bug #18140]
'y' and 'n' are kind of ambiguous. Syck treated y and n literals in
YAML documents as strings. But this is not what the YAML 1.1 spec says.
YAML 1.1 says they should be treated as booleans. When we're dumping
documents, we know it's a string, so adding quotes will eliminate the
"ambiguity" in the emitted document
Fixes#4436a1c30634e
Previously, `+.inf` was not handled correctly. Additionally, the regexp
was checking for inf and NaN, even though these cases are handled earlier
in the condition. Added a few tests to ensure handling some missing
cases.
6e0e7a1e9f
The new class is a wrapper on top of an URI. And then, when you want
credentials redacted, you call `#redacted` that returns a copy of itself,
but with credentials redacted.
9581c2740a
The `initialize` method is already doing a lot and by adding the `Gem::PrintableUri` to redact sensitive information, things are getting complicated and hard to read here. For the start, I have refactored the `initialize` method into a class method called `build`.
4312e8fdf5
The `@uri` variable could be a source URI with a credential. Using `Gem::PrintableUri` to make sure we are redacting sensitive information from it when logging on verbose mode.
f566787211
The `x.source.uri` could be a source URI with a credential. Using `Gem::PrintableUri` to make sure we are redacting sensitive information from it.
8755ee0aaa
We think it's unlikely that `rubygems/defaults/operating_system` could be shipped with a SyntaxError so StandardError could be better choice to prevent "false positives" errors.
1f73e784dd
When loading `rubygems/defaults/operating_system`
- we want to keep it silent if the raised exception is a LoadError
- we want to print a message in other cases and ask users to report the issue to their OS support.
Ruby 3 comes with special error handling for loading `rubygems` and it will show a warning when LoadError exception raised for requiring 'rubygem'.
Because of that, we decided to leave the LoadError scenario as it is.
Reference: d1998d8767/gem_prelude.rb (L1-L5)0a97e12fe1
In vm_call_method_each_type, check for c_call and c_return events before
dispatching to vm_call_ivar and vm_call_attrset. With this approach, the
call cache will still dispatch directly to those functions, so this
change will only decrease performance for the first (uncached) call, and
even then, the performance decrease is very minimal.
This approach requires that we clear the call caches when tracing is
enabled or disabled. The approach currently switches all vm_call_ivar
and vm_call_attrset call caches to vm_call_general any time tracing is
enabled or disabled. So it could theoretically result in a slowdown for
code that constantly enables or disables tracing.
This approach does not handle targeted tracepoints, but from my testing,
c_call and c_return events are not supported for targeted tracepoints,
so that shouldn't matter.
This includes a benchmark showing the performance decrease is minimal
if detectable at all.
Fixes [Bug #16383]
Fixes [Bug #10470]
Co-authored-by: Takashi Kokubun <takashikkbn@gmail.com>
