Implement method coverage - #9676

…all fails its arity check

Unlike a def, whose arity check is an instruction in the body that runs after
ReceiveMethodCoverageInstr has taken the counter, the lambda arity check for a
define_method method runs in Java before the body. A call that failed it left
the entry's counter pending on the thread, and the next run of that block body
(for example a plain call of the same proc) took and counted it.

ProcMethod#call now clears the pending counter once the call returns or raises,
on the path where the entry has a counter at all.

Addresses review feedback on jruby#9676

The initialize of a Ruby subclass of a Java class does not run through
DynamicMethod#call: ConcreteJavaProxy runs it up to its super call
through the exitable interpreter (or a compiled terminal split), and
when the body is a plain super forwarding its arguments it does not run
it at all. None of those paths handed the entry's coverage counter to
the body, so such an initialize reported zero calls.

The hand-off now happens in AbstractIRMethod#startSplitSuperCall, with
the compiled-or-interpreted choice split out into splitSuperCall so that
MixedModeIRMethod can still delegate to its jitted method (which is not
the registered entry and holds no counter). The two ConcreteJavaProxy
shortcuts that skip the Ruby body altogether count the call directly;
they have already established that the arguments match the arity, which
is where MRI fires the CALL event it counts.

…counted

The parser grew and filled its array of starting line counts for every
parse made while coverage was set up, including Coverage.start(methods:
true), where CoverageData#prepareCoverage never looks at it, and
oneshot_lines, where it starts from an empty list instead. The file is
still registered with Coverage in every mode so that it appears in the
result.

Registration, clearing and result conversion all run while holding the
CoverageData lock, so the copy-on-write list was copying the whole array
on every method definition for nothing.

Shorter sentences, no asides in parentheses, and one idea per sentence,
so the comments are easier to read for non-native speakers.

Also move the pending coverage field in ThreadContext above the
constructor's javadoc, which it had been inserted under by mistake, and
regenerate the parser for the changed grammar comment.

A block passed to a call whose arguments are not parenthesized, and a
block passed to a call of a method named like a constant, come through
grammar rules of their own: cmd_brace_block, do_block, and the
primary_value tCOLON2 tCONSTANT rule. None of them recorded where the
block starts and ends, so method coverage reported -1 for both columns
of a method defined from such a block.

Worse, none of them set the block's line from its opening brace or do
keyword either, so the line came from the empty production that starts
the block body, whose start position is left over from whatever was
parsed before it. A call spanning several lines therefore reported the
line its arguments start on rather than the line of the block. That line
is what TracePoint reports for b_call too, so both are now correct.

The three rules do what brace_block already did, and the keys method
coverage reports for these blocks now match MRI.

CoverMethodInstr decodes an operand but wrote none, since neither
OneOperandInstr nor Instr writes operands, so only the operation code
went out. Persisting IR with -Xir.writing while methods mode was on
therefore produced a file that goes out of step at the first
COVER_METHOD and reads back as garbage.

IRScope.endLine is -1 when no source span was recorded, which is still
the case for methods built by Prism. Adding one to convert it to a
1-based line turned that marker into 0, a line number that looks real.
The key then carried two different markers at once, as in
[Foo, :bar, 3, -1, 0, -1].

define_method(:new_name, some_method) binds a RenamedDynamicMethod that
wraps a copy of some_method, and neither the wrapper nor the copy ever
learns the new name: only the id passed to putMethod knows it. The key
therefore carried the name the method was copied from, so

  class A; def foo; end; end
  B.send(:define_method, :bar, A.instance_method(:foo))

reported [B, :foo, ...] where MRI reports [B, :bar, ...]. MRI keys the
entry by its called_id, the name it was defined under, which is what
putMethod already has in hand.

A counter was attached to its DynamicMethod for good: resetCoverage only
dropped the map of results. Three things followed a single completed
run, for the rest of the process.

InvokeSite.buildJittedHandle refuses to bind a call site directly to the
compiled body of a counted method, since the hand-off happens in
DynamicMethod.call. With the counter still attached, every method
defined during the run stayed permanently unbindable, long after anyone
was measuring. Calls also kept writing the counter to the ThreadContext,
and each counter kept an IRScope and a RubyModule alive.

resetCoverage now detaches every counter and invalidates the owners
whose entries changed, so call sites bound to the counting path
re-resolve and can bind directly again. The invalidation runs outside
the CoverageData lock: it takes the hierarchy lock, while a thread
defining a method holds the method table lock and then waits in
registerMethod, so holding both at once could deadlock.

The counter holds its entry weakly, so a method discarded during a run
is not kept alive until the run ends.

peek_result held the lock for the whole conversion so that another
thread could not parse a file or define a method while the result was
being built. The methods hash is keyed by an Array, and hashing one
dispatches Ruby's Array#hash, which dispatches Module#hash on the owner.
So arbitrary Ruby ran under the lock, and it can define a method, which
needs the method table lock.

RubyModule.addMethodInternal takes the two in the other order: it holds
the method table lock and then waits in registerMethod. A thread calling
Coverage.result and a thread defining a method could therefore deadlock.
resetCoverage already avoids exactly this, which is why it compares
modules by identity and invalidates them outside the lock.

The lock now only covers a snapshot of the per-file data. The conversion
runs after it is released. The snapshot shares the counters themselves,
since all that is read from them is final state and a volatile count.

RubyModule.putMethod calls registerMethod for every method entry
whenever coverage is set up, whatever its mode. registerMethod was
synchronized as a whole and decided it had nothing to do only after
taking the lock.

Under a plain Coverage.start, which is what SimpleCov uses, every def,
define_method, attr_accessor, alias and visibility change in the process
therefore contended for the one lock that coverLine takes on every
executed line, to do nothing.

The mode check and the forwarding-entry checks now run before the lock.

Coverage.result(clear: true) built the result and then cleared the
counts as two separate steps, each taking the CoverageData lock. A call
counted between them was reported nowhere: it was not in the result that
had already been built, and its count was then zeroed.

The copy a result is built from now does the clearing as it reads, so
every count is either in the result or still in the counter. For the
method counters that is one atomic read-and-reset, since they are
counted without the lock.

clearCoverage is gone, as is MethodCoverage.clear. Coverage.result was
their only caller.