<enebo[m]>
this strikes me as some extra piece of data which should come from actually building source
<headius[m]>
I agree, and we do build this array during parse but it's not easy to access
<headius[m]>
and I don't know if it would be any more correct
<headius[m]>
this basically emulates that array built in ParserConfiguration that had the bad scaling factor
<enebo[m]>
well I meant as an impl detail since we essentially have access to the AST
<enebo[m]>
This PR will not work against streamed code for instance
<enebo[m]>
not that that is very common
<headius[m]>
you have to give it a filename so I'm not sure that matters
<enebo[m]>
heh ok well a whole in their API :)
<headius[m]>
I guess this is so you can get a completely uncovered base list of counts for a given file without loading it or having coverage one
<headius[m]>
on
<headius[m]>
so if we could do a parse that also exposes this coverage data, without coverage being on, it would be fine too
<enebo[m]>
I don't have any idea why there is a difference if we are looking for newline nodes. I can only guess but it might not matter either if we output matching line events
<headius[m]>
well for example that first missing coverable line comes from another multi-line construct:
<enebo[m]>
so we actually make a newline for any call if I recall
<enebo[m]>
Although maybe I am over simplifying that
<enebo[m]>
It could be the iseq advantage!
<enebo[m]>
in IRBuilder I believe we do not emit the same line instr twice
<enebo[m]>
That actually may be a clue to this...maybe I have an interesting comment in there
<enebo[m]>
(note: that would be a different line for us)
<headius[m]>
gimme a review explaining we'll look into the differences outside PR
<enebo[m]>
also since we output call before hash we may line line 4, line 1 out of order too
<headius[m]>
so there's obviously weird things afoot that are not fixable in this PR
<headius[m]>
yeah I am just using actual node line numbers for this logic
<enebo[m]>
yeah we maybe can eliminate some newlines where we couldn't before
<enebo[m]>
in the past newline was used as an "insulating" node...so if you have a construct it would check a child and say do this if it is an arraynode or whatnot...but then they would newline wrap it and then it would not do that action
<enebo[m]>
After they followed us in removing it as a full-fledged node I believe all that logic went away
<enebo[m]>
The parser is complicated we maybe still have something in there adding extra newline field sets we do not need
<headius[m]>
ah right
<enebo[m]>
If you would have asked me last week I would have said who cares :)
<headius[m]>
yeah well I was very surprised danmayer said we passed everything after he worked around missing `line_stub`
<headius[m]>
maybe he has bad tests
<headius[m]>
or maybe it doesn't matter that much
<enebo[m]>
no it is likely we probably emit things off but still overlapping in some way with a single multiline statement
<enebo[m]>
if they use parser gem it provides start/end line ranges and we hit something in that range
<enebo[m]>
or at least this is my guess
<enebo[m]>
return 0 or 1 in something from 0-3 will still say 0-3 was hit
<enebo[m]>
without more knowledge it feels like a good guess :)
<enebo[m]>
it is also how I would tackle coverage
<headius[m]>
I have no explanation why hash is different
<enebo[m]>
my very vague assertion above also feels good :)
<enebo[m]>
{} can be hash OR a block
<enebo[m]>
perhaps newline is not emitted until first thing in either
<enebo[m]>
in a block first line would be the thing which mattered as well
<enebo[m]>
but then all other lines as well
<enebo[m]>
my main reason for guessing that is contents of hash or block are parsed before knowing it is one or the other
<enebo[m]>
LALR and all that
<headius[m]>
ok different topic quick... did that jcodings change get merged and released?
<enebo[m]>
the one I asked lopex about this morning...I don't know if he did it or not yet
<headius[m]>
ok
<enebo[m]>
and I do not know enough about jcodings to know if it is correct so I did not do it