Remove `NewlineTest`?

[Earlopain]

It often breaks just because some source file changed. Latest is ruby/ruby@f4813a3 which needs to be reverse synced. It looks like in the last two years the list of excludes has just grown and nobody seems to care all that much. https://github.com/ruby/prism/commits/main/test/prism/newline_test.rb

It compares newline flags in the prism ast against those from iseq. But either something is not correct or it's not an exact science (currently the rubyvm result is already postprocessed in some way).

Everything is already mostly recorded in the ast snapshot + the visitor does a small bit of work as well based on that ast. So it only really compares against RubyVM with parse.y. I would like to stop doing that. Thoughts?

[kddnewton]

This is as good a place as any to put a bunch of context on this particular feature.

In order to support tracepoint for the LINE event, nodes are marked as candidates for emitting the LINE event. These candidates are any nodes that were on their own within a list of statements (effectively anything that got upgraded from an expression to a statement), or any if expressions or unless expressions. Then when compiling the AST to YARV bytecode, the first node to be visited in the compiler that is a candidate effectively claims that line in source, and any other candidates that are visited on that line do not emit the LINE event.

The loosely maps to expressions that are on their own line emitting LINE events, but it gets weird when you have an expression like an assignment with a newline after the =.

Historically, it has been super difficult for other implementations of Ruby to match this behavior, because it effectively means duplicating the exact order that the YARV bytecode compiler visits nodes in the tree, which itself is not actually stable between any two versions (or even within a version). So @eregon added a Ruby and Java API that attempts to replicate that, but it's basically a best-effort thing because it's exceedingly difficult to get exactly right.

The best long-term solution would be for Ruby core to actually define exactly how the LINE event determines when it should be emitted, as right now it's just "whatever the compiler does is canonical", which isn't exactly reliable. But that's a longer term solution.

In the meantime, I am actually very in favor of getting rid of this test. I agree it's not actually providing any safety, because we just keep adding to the omission list. I think it served us well while we were building things, but at this point it's just noise. I'll wait for @eregon's take on it though.