Multiline annotations: `Context` labels incorrectly colored as `Primary` if they fully overlap another `Primary` label

[tonywu6]

If there is an annotation of AnnotationKind::Primary that spans multiple lines, and also an annotation of AnnotationKind::Context that has the exact same span as the primary annotation, then the context label is colored using the primary color instead of the context color.

For example, in this test case, both annotations has span 35..58:

use annotate_snippets::{AnnotationKind, Level, Renderer, Snippet, renderer::DecorStyle};

use snapbox::{assert_data_eq, file};

#[test]
fn case() {
    let source = r#"This is example of two annotations spanning
multiple lines with the exact same byte range."#;

    // spanning
    // multiple lines
    let span = 35..58;

    let input = &[Level::ERROR.primary_title("attention!").element(
        Snippet::source(source)
            .path("foo.txt")
            .annotation(
                AnnotationKind::Primary
                    .span(span.clone())
                    .label("primary label"),
            )
            .annotation(
                AnnotationKind::Context
                    .span(span.clone())
                    .label("context label"),
            ),
    )];

    let expected_ascii = file!["ann_multiline_overlapping.ascii.term.svg": TermSvg];
    let renderer = Renderer::styled();
    assert_data_eq!(renderer.render(input), expected_ascii);

    let expected_unicode = file!["ann_multiline_overlapping.unicode.term.svg": TermSvg];
    let renderer = renderer.decor_style(DecorStyle::Unicode);
    assert_data_eq!(renderer.render(input), expected_unicode);
}

---

Notably, this visual error doesn't otherwise appear:

• If the spans aren't equal:

  

  (I notice that the renderer will collapse the line drawings if the spans are fully equal. Perhaps it is related to that?)

• Or if the order in which the annotations are added is reversed (i.e. adding the context span first):

  

---

Also, possibly related to #427, with the added use of highlight_source(true) on the primary label, there is an additional visual glitch:

.annotation(
    AnnotationKind::Primary
        .span(span.clone())
        .label("primary label"),
        .highlight_source(true),
)
.annotation(
    AnnotationKind::Context
        .span(span.clone())
        .label("context label"),
),

[poliorcetics]

From a quick investigation:

The main issue described in the test case happens because of

annotate-snippets-rs/src/renderer/source_map.rs

Lines 238 to 243 in 5a91005

	if primary_spans
	.iter()
	.any(|(s, e)| a.start == *s && a.end == *e)
	{
	a.kind = AnnotationKind::Primary;
	}

.

Removing it breaks

annotate-snippets-rs/tests/rustc_tests.rs

Lines 319 to 377 in 5a91005

	fn triple_exact_overlap() {
	let source = r#"
	fn foo() {
	X0 Y0 Z0
	X1 Y1 Z1
	X2 Y2 Z2
	}
	"#;
	let input = &[Level::ERROR.primary_title("foo").element(
	Snippet::source(source)
	.line_start(1)
	.path("test.rs")
	.annotation(
	AnnotationKind::Primary
	.span(14..38)
	.label("`X` is a good letter"),
	)
	.annotation(
	AnnotationKind::Context
	.span(14..38)
	.label("`Y` is a good letter too"),
	)
	.annotation(AnnotationKind::Context.span(14..38).label("`Z` label")),
	)];
	// This should have a `^` but we currently don't support the idea of a
	// "primary" annotation, which would solve this
	let expected_ascii = str![[r#"
	error: foo
	--> test.rs:3:3
	|
	3 | / X0 Y0 Z0
	4 | | X1 Y1 Z1
	5 | | X2 Y2 Z2
	| | ^
	| | |
	| | `X` is a good letter
	| |____`Y` is a good letter too
	| `Z` label
	"#]];
	let renderer = Renderer::plain();
	assert_data_eq!(renderer.render(input), expected_ascii);
	let expected_unicode = str![[r#"
	error: foo
	╭▸ test.rs:3:3
	│
	3 │ ┏ X0 Y0 Z0
	4 │ ┃ X1 Y1 Z1
	5 │ ┃ X2 Y2 Z2
	│ ┃ ╿
	│ ┃ │
	│ ┃ `X` is a good letter
	│ ┗━━━━`Y` is a good letter too
	╰╴ `Z` label
	"#]];
	let renderer = renderer.decor_style(DecorStyle::Unicode);
	assert_data_eq!(renderer.render(input), expected_unicode);
	}

because the lines are overriden by the last annotation it seems, which is a AnnotationKind::Context, not Primary anymore.

I see several potential solutions and I'm not sure which would be preferred by maintainers:

1. Instead of changing the kind to AnnotationKind::Primary, add a new boolean tracking if there is a primary on the same range. It's more state and a bigger struct and I don't know how perf-sensitive this crate is.
2. Create a Vec, Hashmap or whatever tracking if there is a primary for this range instead of changing the kind and pass that to rendering functions.
3. Keep two annotation kind in a structure: line_kind and kind, switch line_kind to AnnotationKind::Primary but not the main kind.