Support the latest source_span #34
Conversation
test/refactor_test.dart
Outdated
| @@ -84,15 +84,15 @@ main() { | |||
| _span(2, 1, map, file), | |||
| "line 2, column 1: \n" | |||
| " ,\n" | |||
| "2 | 0*23456789\n" | |||
| " | ^\n" | |||
| "1 | 0*23456789\n" | |||
There was a problem hiding this comment.
why doesn't this match the line number above?
There was a problem hiding this comment.
Good question. That looks like a bug. I'll fix it in source_span.
There was a problem hiding this comment.
Okay, it looks like this is trickier than I thought. We're in a difficult position where there's no way, given a point span (that is, a span with length 0) at column 0 and a context line (such as "0*23456789\n"), to disambiguate whether that point refers to the beginning of that line or the beginning of the next line. In this case it's the former, but it may be the latter for spans at the end of files that end in newlines.
We should really just have an index field in SourceSpanWithContext to disambiguate this, but adding that is non-trivial. A number of downstream users implement FileSpan as an interface, which implements SourceSpanWithContext. This means that we can't add new fields without it being a breaking change.
In the long term, we probably want to release source_span 2.0.0 with that field, as well as probably a FileSpanMixin so that we can tell users "don't treat this as an interface". In the meantime, I'll make sure that FileSpan.context only includes the line that the span appears on. This'll make end-of-file spans look bad, but it'll fix this case, which is probably more common.
source_span 1.5.3 was generating the wrong output here.
|
@natebosch I fixed source_span and updated these tests. PTAL |
No description provided.