| Age | Commit message (Collapse) | Author |
|
Notes:
Merged: https://github.com/ruby/ruby/pull/8348
|
|
https://github.com/ruby/yarp/commit/b48067b067
|
|
The test sometimes fails with:
```
1) Failure:
TestProcess#test_warmup_frees_pages [test/ruby/test_process.rb:2749]:
<0> expected but was
<1>.
```
I think there's a page with an object that needs finalization, so run
GC to clear that object.
|
|
Notes:
Merged-By: jemmaissroff
|
|
The test sometimes fails with:
```
1) Failure:
TestProcess#test_warmup_run_major_gc_and_compact [test/ruby/test_process.rb:2712]:
<2> expected but was
<3>.
```
|
|
Closes https://github.com/ruby/yarp/pull/1367
https://github.com/ruby/yarp/commit/b1ab54f526
|
|
Essentially, this change updates `yp_unescape_calculate_difference` to
not create syntax errors, and we rely entirely on
`yp_unescape_manipulate_string` to report syntax errors.
To do that, this PR adds another (!) parameter to `unescape`:
`yp_list_t *error_list`. When present, `unescape` reports syntax
errors (and otherwise does not).
However, an edge case that needed to be addressed is reporting syntax
errors in this case:
?\u{1234 2345}
In a string context, it's possible to have multiple codepoints by
doing something like `"\u{1234 2345}"`; however, in the character
literal context, this is a syntax error -- only a single codepoint is
allowed.
Unfortunately, when `yp_unescape_manipulate_string` is called, there's
nothing to indicate that we are in a "character literal" context and
that only a single codepoint is valid.
To make this work, this PR:
- introduces a new static utility function in yarp.c,
`yp_char_literal_node_create_and_unescape`, which is called when
we're parsing `YP_TOKEN_CHARACTER_LITERAL`
- introduces a new (unexported) function,
`yp_unescape_manipulate_char_literal` which does the same thing as
`yp_unescape_manipulate_string` but tells `unescape` that only a
single codepoint is expected
https://github.com/ruby/yarp/commit/f6a65840b5
|
|
https://github.com/ruby/yarp/commit/7b090bc23d
|
|
* Consistent with ClassVariableWriteNode, ConstantWriteNode, InstanceVariableWriteNode, GlobalVariableWriteNode.
* Fixes desugaring of local variable with operators.
https://github.com/ruby/yarp/commit/9a66737775
|
|
* Consistent with ClassVariableWriteNode, ConstantWriteNode, InstanceVariableWriteNode, LocalVariableWriteNode.
* Fixes desugaring of global variable with operators.
https://github.com/ruby/yarp/commit/fb5a53fc0b
|
|
without a temporary variable
* See https://github.com/ruby/yarp/pull/1329#discussion_r1310775433 for details.
https://github.com/ruby/yarp/commit/f0fdcba0c3
|
|
call
Allow compstmt in the first argument of command call wrapped with parenthesis
like following arguments with parenthesis.
Notes:
Merged: https://github.com/ruby/ruby/pull/8347
|
|
file
(https://github.com/ruby/yarp/pull/1371)
* refactor: move EOF check into yp_unescape_calculate_difference
parser_lex is a bit more readable when we can rely on that behavior
* fix: octal and hex digits at the end of a file
Previously this resulted in invalid memory access.
* fix: unicode strings at the end of a file
Previously this resulted in invalid memory access.
* Unterminated curly-bracket unicode is a syntax error
https://github.com/ruby/yarp/commit/21cf11acb5
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/8343
|
|
getblockparamproxy for "ifunc" behaves identically to iseq, in just
pushing rb_block_param_proxy.
Notes:
Merged: https://github.com/ruby/ruby/pull/8300
|
|
OpenBSD and Solaris behave differently here.
Linux does deliver the empty packet, which is questionable
as it's undistinguishable from a closed connection.
It seems that OpenBSD and Solaris simply drop it.
We could test the platform before doing the assertion, but
it would likely be fragile, and the entire web recommend
to not ever send an empty packet, so the value of this
assertion is low.
Notes:
Merged: https://github.com/ruby/ruby/pull/8338
|
|
The old algorithm could calculate an undercount for the initial pages
due to two issues:
1. It did not take into account that some heap pages will have one less
slot due to alignment. It assumed that every heap page would be able
to be fully filled with slots. Pages that are unaligned with the slot
size will lose one slot. The new algorithm assumes that every page
will be unaligned.
2. It performed integer division, which truncates down. This means that
the number of pages might not actually satisfy the number of slots.
This can cause the heap to grow in `gc_sweep_finish_size_pool` after
allocating all of the allocatable pages because the total number of
slots would be less than the initial configured number of slots.
Notes:
Merged: https://github.com/ruby/ruby/pull/8333
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/7144
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/7144
|
|
This commit changes RUBY_GC_HEAP_INIT_SIZE_{40,80,160,320,640}_SLOTS to
RUBY_GC_HEAP_{0,1,2,3,4}_INIT_SLOTS. This is easier to use because the
user does not need to determine the slot sizes (which can vary between
32 and 64 bit systems). They now just use the heap names
(`GC.stat_heap.keys`).
Notes:
Merged: https://github.com/ruby/ruby/pull/8335
|
|
https://github.com/ruby/yarp/commit/5d9b048971
|
|
* [YARP] Compile ProgramNode as ScopeNode
Notes:
Merged-By: jemmaissroff
|
|
* [YARP] Fixed several popped instructions
* [YARP] Correctly compiling class path
Notes:
Merged-By: jemmaissroff
|
|
Also, a similar test and fix for interpolated regular expressions.
This snippet:
<<-A.g//,
A
/{/, ''\
previously created a regular expression node with inverted start and
end:
RegularExpressionNode(14...13)((14...15), (15...21), (12...13), ", ''", 0),
which failed an assertion during serialization.
After this change:
RegularExpressionNode(12...15)((14...15), (15...21), (12...13), ", ''", 0),
Found by the fuzzer.
https://github.com/ruby/yarp/commit/5fef572f95
|
|
The snippet added in this commit previously resulted in a CallNode
with inverted start and end locations:
> AssocNode(15...13)(
> CallNode(15...13)(
StringNode(15...17)((15...16), (16...16), (16...17), ""),
nil,
(12...13),
nil,
ArgumentsNode(12...13)([MissingNode(12...13)()]),
nil,
nil,
0,
"/"
),
MissingNode(13...13)(),
(13...13)
),
which failed an assertion during serialization.
After this change, it looks better:
> AssocNode(12...13)(
> CallNode(12...17)(
StringNode(15...17)((15...16), (16...16), (16...17), ""),
nil,
(12...13),
nil,
ArgumentsNode(12...13)([MissingNode(12...13)()]),
nil,
nil,
0,
"/"
),
MissingNode(13...13)(),
(13...13)
),
Found by the fuzzer.
https://github.com/ruby/yarp/commit/040aa63ad6
|
|
The presence of the heredocs in this snippet with invalid syntax:
for <<A + <<B
A
B
causes the MissingNode to have a location after other nodes in the
list, resulting in a StatementsNode with inverted start and end
locations:
[ForNode(0...14)(
MultiWriteNode(4...7)([InterpolatedStringNode(4...7)((4...7), [], (14...16))], nil, nil, nil, nil),
MissingNode(16...16)(),
> StatementsNode(16...14)(
[MissingNode(16...16)(), InterpolatedStringNode(10...13)((10...13), [], (16...18)), MissingNode(13...14)()]
),
(0...3),
(16...16),
nil,
(14...14)
)]
which failed an assertion during serialization.
With this fix, the node's locations are:
[ForNode(0...14)(
MultiWriteNode(4...7)([InterpolatedStringNode(4...7)((4...7), [], (14...16))], nil, nil, nil, nil),
MissingNode(16...16)(),
> StatementsNode(10...16)(
[MissingNode(16...16)(), InterpolatedStringNode(10...13)((10...13), [], (16...18)), MissingNode(13...14)()]
),
(0...3),
(16...16),
nil,
(14...14)
)]
Found by the fuzzer.
https://github.com/ruby/yarp/commit/09bcedc05e
|
|
https://github.com/ruby/yarp/commit/4c76f4a0c0
|
|
https://github.com/ruby/yarp/commit/440cf93a70
|
|
https://github.com/ruby/yarp/commit/be5cb60c83
|
|
https://github.com/ruby/yarp/commit/1f94f55fcb
|
|
https://github.com/ruby/yarp/commit/0556f971ce
|
|
https://github.com/ruby/yarp/commit/d24f62566e
|
|
Previously this resulted in invalid memory access.
Found by the fuzzer.
https://github.com/ruby/yarp/commit/b248553dd6
|
|
Previously this resulted in invalid memory access.
Found by the fuzzer.
https://github.com/ruby/yarp/commit/ec4abd87f4
|
|
Previously this resulted in invalid memory access.
Found by the fuzzer.
https://github.com/ruby/yarp/commit/55b9dfb41c
|
|
Previously this resulted in invalid memory access.
Found by the fuzzer.
https://github.com/ruby/yarp/commit/78ed75ed75
|
|
Previously this resulted in invalid memory access.
Found by the fuzzer.
https://github.com/ruby/yarp/commit/af5b85a27a
|
|
Previously this resulted in invalid memory access.
Found by the fuzzer.
https://github.com/ruby/yarp/commit/c86b4907b4
|
|
Previously this resulted in invalid memory access.
Found by the fuzzer.
https://github.com/ruby/yarp/commit/a1c9404906
|
|
Previously this resulted in invalid memory access.
Found by the fuzzer.
https://github.com/ruby/yarp/commit/178862e2ca
|
|
Previously this resulted in invalid memory access.
Found by the fuzzer.
https://github.com/ruby/yarp/commit/c781c9fcd2
|
|
Previously this resulted in invalid memory access as well as a
cascading failed assertion:
src/enc/yp_unicode.c:2224: yp_utf_8_codepoint: Assertion `n >= 1' failed.
Found by the fuzzer.
https://github.com/ruby/yarp/commit/a34c534440
|
|
Note that we call `YARP.dump` for these fuzzer tests to better match
the fuzz.parse harness, which also serializes.
https://github.com/ruby/yarp/commit/032ad047e9
|
|
Class variables, global variables, constants, and constant paths
should actually desugar to `defined?` instead of just reading the
value.
https://github.com/ruby/yarp/commit/551a59b876
|
|
|
|
https://github.com/ruby/yarp/commit/b85e01d77d
|
|
https://github.com/ruby/yarp/commit/687213d2e3
|
|
|
|
https://github.com/ruby/yarp/commit/b01711396f
|
|
[Bug #19012]
man recvmsg(2) states:
> Return Value
> These calls return the number of bytes received, or -1 if an error occurred.
> The return value will be 0 when the peer has performed an orderly shutdown.
Not too sure how one is supposed to make the difference between a packet of
size 0 and a closed connection.
Notes:
Merged: https://github.com/ruby/ruby/pull/6407
|