XAML: Provide better support for AdditionalFiles analyzers

[mgoertz-msft]

Problem
Currently the only way to create analyzers for additional files is via RegisterCompilationStartAction for example and accessing them via AnalyzerOptions.AdditionalFiles. Unfortunately this means that there is no way for analyzer optimizations, such as running only for a currently open additional document for example. This places the burden of any potential optimizations on each analyzer implementation and could result in performance problems.

Justification
With the internal DocumentDiagnosticAnalyzers being frowned upon and eventually going away an official replacement solution for additional files is needed to support analyzers for non-core Roslyn languages such as XAML.

Ask
Provide support for something like an AdditionalDocumentDiagnosticAnalyzer for example that can be optimized for additional files scenarios.

[jinujoseph]

cc @mavasani

[mavasani]

@sharwell I believe the request here is to support first class analysis callbacks for additional files, similar to source files. This will allow analyzers that analyze additional files to report diagnostics on opened additional files with the default analysis scope (Open documents). Additionally, it would be easier for third parties to write their own suggested actions (code fixes) for diagnostics in additional files.

@mgoertz-msft Can you confirm if this correctly represents your feature request?

[sharwell]

@mavasani That makes sense, thanks!

[mgoertz-msft]

@mavasani Yes, that's exactly the purpose of this request so we can represent XAML documents in additional files and run analyzers on XAML documents.

[sharwell]

@mavasani Can you create an API proposal for review derived from the current syntax tree analysis APIs?

[mavasani]

@sharwell Sure, I will create and post an API proposal. We would need to have a design review with the compiler team before working on the implementation.

[mavasani]

Proposal

Design

Design API surface for additional file actions analogous to SyntaxTree actions:

1. Add a new AdditionalFileAnalysisContext, analogous to SyntaxTreeAnalysisContext:

    public struct AdditionalFileAnalysisContext
    {
        public AdditionalText File { get; }
        public AnalyzerOptions Options { get; }
        public CancellationToken CancellationToken { get; }
        public Compilation Compilation { get; }

        public void ReportDiagnostic(Diagnostic diagnostic);
    }

2. Add a new RegisterAdditionalFileAction API on all relevant analysis contexts where RegisterSyntaxTreeAction is provided:

        public void RegisterAdditionalFileAction(Action<AdditionalFileAnalysisContext> action);

Implementation

Identical analyzer action semantics to syntax tree action callbacks. From https://github.com/dotnet/roslyn/blob/master/docs/analyzers/Analyzer%20Actions%20Semantics.md:

A syntax tree action is invoked once per source document. A syntax tree action can be expected to be invoked as early as possible after a document is parsed, but this is not guaranteed.

Open question

Should we expose a similar API for analyzer config files? This will allow us to write analyzers for mistakes in editorconfig files, which show up on opening these files. For example, we can finally address #19055 if RegisterAnalyzerConfigFileAction were to be added.

[mavasani]

@sharwell @vatsalyaagrawal We can bring the above design proposal for discussion at the next IDE design meeting if we can have a member from compiler team present at the discussion.

[mavasani]

@mgoertz-msft can you confirm the above API would meet your request?

[mgoertz-msft]

@mavasani Looks like that should work. I wonder if instead of public AdditionalText File { get; } it should be public AdditionalDocument File { get; }. What do you think? Would that be possible?

[sharwell]

AdditionalDocument is a workspace API. It does not exist in compilation/analyzer scenarios.

[mavasani]

The API proposal was approved at the design meeting.

[mavasani]

@mgoertz-msft FYI that your original feature request has now been implemented for 16.8 P1 with #45076. I will keep this issue open to track exposing a similar API for analyzer config files.

[mavasani]

I will keep this issue open to track exposing a similar API for analyzer config files.

Now tracked with #64213