Multi-span diagnostics in the LSP

[MichaReiser]

Red Knot only highlights the primary diagnostic range today.

Explore how to display multi-span diagnostics. This is something that r-a seems to support.

[InSyncWithFoo]

Do you mean something like this?

Rust Analyzer does the same, as far as I see:

RustRover has something fancier: it displays messages inline on focus (native feature).

[MichaReiser]

Yes, this is the kind of functionality we want to explore.

[InSyncWithFoo]

The property in question is relatedInformation:

export interface Diagnostic {
	/**
	 * An array of related diagnostic information, e.g. when symbol-names within
	 * a scope collide all definitions can be marked via this property.
	 */
	relatedInformation?: DiagnosticRelatedInformation[];
}

...where DiagnosticRelatedInformation is defined as:

/**
 * Represents a related message and source code location for a diagnostic.
 * This should be used to point to code locations that cause or are related to
 * a diagnostics, e.g when duplicating a symbol in a scope.
 */
export interface DiagnosticRelatedInformation {
	/**
	 * The location of this related diagnostic information.
	 */
	location: Location;

	/**
	 * The message of this related diagnostic information.
	 */
	message: string;
}

Currently, Red Knot always specifies related_information: None. This should be changed to use data from secondary messages instead.

I'll submit a PR tomorrow.

[MichaReiser]

Thank you, but We want to do sone design exploration first and we're also in the middle of rewriting the diagnostics

[InSyncWithFoo]

In that case, here's the meat of the changes, just for the records:

let related_information = diagnostic
    .secondary_messages()
    .iter()
    .filter_map(|info| {
        let span = info.span();
        let path = span.file().path(db).as_system_path()?;

        let uri = Url::from_file_path(path).ok()?;
        let range = span_to_range(span);

        Some(DiagnosticRelatedInformation {
            location: Location { uri, range },
            message: info.message().to_string(),
        })
    })
    .collect::<Vec<_>>();

[MichaReiser]

Thanks, this is great. Sorry for being so defensive about it. The main purpose of this issue is to explore the different options that you list listed in your previous reply and decide what UX we want. I'm glad to see that the implementation might be much easier than I assumed it would be

[MichaReiser]

I think there are two things here:

1. Use related information on LSPs that support it
2. Add some textual rendering for LSPs that don't support related information.

[InSyncWithFoo]

@MichaReiser That sounds about right. The "textual rendering" can then contain links that lead to certain source code locations instead of full-blown snippets.