See jruby/jruby#7570 for some of the justification for this move. We only
require the parser from SnakeYAML, but in the original form it is
encumbered with Java object serialization code that keeps getting
flagged as a CVE risk. We disagree with the assessment, at least
as it pertains to JRuby (we do not use the code in question) but
our inclusion of the library continues to get flagged by auditing
tools.
This commit starts the process of moving to the successor library,
SnakeYAML Engine. The parser API is largely unchanged, except as
seen in this commit. No Java exceptions are thrown, but a number
of Psych tests fail (possibly due to Engine being YAML 1.2 only).
Currently Bundler needs to do cumbersome operations to revert custom
RubyGems require on a `bundler/setup` context. This causes issues when
third party gems also monkeypatch require, since Bundler will also undo
those decorations.
This commit allows it to use the simpler approach of properly telling
RubyGems that it needs to default to built-in require without any extra
magic.
1df5009e14
Co-authored-by: Xavier Noria <fxn@hashref.com>
Given an existing application using native gems (e.g., nokogiri)
And a lockfile generated with a stable ruby version
When we test the application against ruby-head and `bundle install`
Then bundler should fall back to the generic ruby platform gem
Note that this test has been passing since 45931ac9
0ecc6de378
"Appropriate" for me being ifdefs which:
1) span enough lines to be hard-to-follow (I need big fonts to see)
2) nested within other ifdefs, or within large functions
(I have a short attention span)
rb_file_expand_path_internal is the prime example of a large
function I struggle to understand due to the amount of
platform-specific ifdefs. Hopefully this helps others with poor
vision and/or short attention spans.
the final copying of the extension into place has been slimmed
down, reflecting that it only needs to copy a single file, rather
than replicating the more involved process used for a C ext
this also refactors #build so that #cargo_crate_name only needs
to be called once, and hopefully the build flow is easier to
understand
5a0d7f2e6c
This was broken in ec3542229b. That commit
didn't handle cases where extended mode was turned on/off inside the
regexp. There are two ways to turn extended mode on/off:
```
/(?-x:#y)#z
/x =~ '#y'
/(?-x)#y(?x)#z
/x =~ '#y'
```
These can be nested inside the same regexp:
```
/(?-x:(?x)#x
(?-x)#y)#z
/x =~ '#y'
```
As you can probably imagine, this makes handling these regexps
somewhat complex. Due to the nesting inside portions of regexps,
the unassign_nonascii function needs to be recursive. In
recursive mode, it needs to track both opening and closing
parentheses, similar to how it already tracked opening and
closing brackets for character classes.
When scanning the regexp and coming to `(?` not followed by `#`,
scan for options, and use `x` and `i` to determine whether to
turn on or off extended mode. For `:`, indicting only the
current regexp section should have the extended mode
switched, recurse with the extended mode set or unset. For `)`,
indicating the remainder of the regexp (or current regexp portion
if already recursing) should turn extended mode on or off, just
change the extended mode flag and keep scanning.
While testing this, I noticed that `a`, `d`, and `u` are accepted
as options, in addition to `i`, `m`, and `x`, but I can't see
where those options are documented. I'm not sure whether or not
handling `a`, `d`, and `u` as options is a bug.
Fixes [Bug #19379]
[Bug #19390]
We shouldn't check the string length when skipping zeros, as the
string might only contains zero characters, resulting in an empty string.
* Make changes to docs in ractor.rb
Mainly English changes to make things more clear, and to fix minor
non-idiomatic phrases. Also clarified difference between frozen and
shareable objects.
* More minor changes to Ractor docs.
Prior to this commit `bundle binstubs --standalone --all` would output a
warning about not being able to generate a standalone binstub for
bundler.
This warning predates the `--all` option, and I don't think it makes
sense in this context. The warning makes good sense when explicitly
trying to generate a bundler standalone binstub with `bundle binstubs
bundler --standalone`, since that command won't do what the user might
have expected. But `--all` is not specifically asking for bundler, and
having it report each time that the bundler binstubs could not be
generated does not seem particularly helpful. The only way to make that
warning go away would be to stop using `--standalone --all`.
This commit skips the warning when running with the `--all` option.
e6a72e19eb
Rust 1.58.0 unfortunately doesn't provide facilities to control symbol
visibility/presence, but we care about controlling the list of
symbols exported from libruby-static.a and libruby.so.
This commit uses `ld -r` to make a single object out of rustc's
staticlib output, libyjit.a. This moves libyjit.a out of MAINLIBS and adds
libyjit.o into COMMONOBJS, which obviates the code for merging libyjit.a
into libruby-static.a. The odd appearance of libyjit.a in SOLIBS is also
gone.
To filter out symbols we do not want to export on ELF platforms, we use
objcopy after the partial link. On darwin, we supply a symbol list to
the linker which takes care of hiding unprefixed symbols.
[Bug #19255]
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
YJIT will need it to address symbol leakage issue. Fallback to `:` when
OBJCOPY is not available on the system.
Co-authored-by: Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
This was a difference from using a GNU toolchain previously. It wasn't a
problem because we don't invoke $(LD) in the Makefile currently. YJIT
will want to invoke LD, so needs this consistency.
possible
(https://github.com/ruby/fiddle/pull/120)
WG14 N2350 made very clear that it is an UB having type definitions
within "offsetof" [1]. This patch enhances the implementation of macro
ALIGN_OF to use builtin "_Alignof" to avoid undefined behavior when
using std=c11 or newer
clang 16+ has started to flag this [2]
Fixes build when using -std >= gnu11 and using clang16+
Older compilers gcc < 4.9 or clang < 8 has buggy _Alignof even though it
may support C11, exclude those compiler versions
[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm
[2] https://reviews.llvm.org/D133574
Signed-off-by: Khem Raj <raj.khem@gmail.com>
ad6c9aa826
(https://github.com/ruby/fiddle/pull/119)
The documentation for `Fiddle.dlwrap` and `Fiddle.dlunwrap` were not
very accurate and pretty confusing. This commit updates the
documentation so it's easier to understand what the methods do.
