SourceAnnotation underline displays offset from range

[gipsond]

I was getting #24 with v0.6.1, but not anymore. Unfortunately I got a similar problem when I tried to update to v0.7.0.

Here's with v0.6.1:

error: invalid immediate, couldn't parse number (was: 30_2)
 --> .\add.asm:1:6
  |
...
5 | .ORIG x30_2
  |       ^^^^^ invalid immediate here
  |

and with v0.7.0, removing the DisplayListFormatter and adding default FormatOptions to the snippet:

error: invalid immediate, couldn't parse number (was: 30_2)
 --> .\add.asm:1:11
  |
...
5 |   .ORIG x30_2
  |  ___________^
6 | | AND R1, R1, R1
  | |____^ invalid immediate here
  |

add.asm has 4 lines before that error, each ending in CRLF. It seems like the offset is in the other direction now.

Originally posted by @gipsond in #24 (comment)

[Nadrieril]

Oh, #27 didn't fix the bug properly. As I said here, one cannot use .lines() for this.
The relevant change in #27 is that they removed the "+1" in this line:

annotate-snippets-rs/src/display_list/from_snippet.rs

Line 186 in 7e73a1b

let line_length = line.chars().count() + 1;

What this does is that instead of treating each line ending as 2 chars, they treat it as 1 char. But the correct fix is to distinguish between the different types of line endings.
Generally I don't think char indexing is really what you want anyways, because unicode makes everything complicated.

[zzau13]

@Nadrieril Can you post the Snippet and expected output?

[Nadrieril]

This is the exact same issue as in #24, except that in #24 it failed on \n line endings and succeeded on \r\n endings, but now it's the reverse. I don't have code that triggers this available, but any code with a line ending in \r\n and a snippet pointing somewhere after that line should show the error.

[Nadrieril]

Actually, here you go:

Snippet {
    title: Some(
        Annotation {
            id: None,
            label: Some(
                "oops".to_string(),
            ),
            annotation_type: AnnotationType::Error,
        },
    ),
    footer: vec![],
    slices: vec![
        Slice {
            source: "First line\r\nSecond oops line".to_string(),
            line_start: 1,
            origin: Some(
                "<current file>".to_string(),
            ),
            annotations: vec![
                SourceAnnotation {
                    range: (
                        19,
                        23,
                    ),
                    label: "oops".to_string(),
                    annotation_type: AnnotationType::Error,
                },
            ],
            fold: true,
        },
    ],
    opt: Default::default(),
}

Output:

error: oops
 --> <current file>:2:9
  |
1 | First line
2 | Second oops line
  |         ^^^^ oops
  |

Expected:

error: oops
 --> <current file>:2:9
  |
1 | First line
2 | Second oops line
  |        ^^^^ oops
  |

The shift gets linearly worse when there are more lines.

[zzau13]

Ok it is easy to solve.

The other cases without "\r\n" as the end of the line, have you seen any other problem?
Coverage is limited and I don't know how it can work in certain extreme cases.

I would greatly appreciate your help detecting these extreme cases and adding coverage since I want to use it in my template engine, thanks !!

[Nadrieril]

This is the only problem I am aware of

[zbraniecki]

@Nadrieril can you try master! @botika wrote a patch for the line endings!

[Nadrieril]

The patch looks good ! As far as I'm concerned this is fixed.
I didn't encounter that particular problem in real code however, I was just helping. @gipsond can you try master ? It should be fixed.

[zbraniecki]

I released 0.8. Please, comment if the bug still exists.