EditorConfig settings don't apply to diagnostics with locations in AdditionalFiles

[agocke]

The root of this issue is what to do about the APIs.

Right now, all the diagnostic options that are applied by the compiler are either on the CompilationOptions or on the SyntaxTree. For AdditionalFiles, the most logical analogous place is directly on the AdditionalText class. However, the compiler never sees this class, so it can't be used for filtering. Moreover, the source of a SyntaxTree for diagnostic filtering is the Location, which has a SyntaxTree property. There's no corresponding AdditionalFile to grab off the location.

Even worse, the way that Locations are produced right now, if you want to create a diagnostic in an AdditionalFile, you must pass the file path, not an AdditionalFile. So if we want to let EditorConfig files filter diagnostics already created on AdditionalFiles, we have to actually map a path, not an AdditionalFile.

The question is how to do this and where to add the APIs.

[MeikTranel]

Can we get this back into planning. The last mentioned symptom issue was closed as "Solved Externally" more than a year ago and i don't think it's a good state of affairs - additionalfile based sourcegenerators and meta analysers are prime use cases - them being second class citizens to the configuration aspect of analyzers is probably something we shouldn't let fester for too long (after all editorconfig support was added to get rid of the configuration file armageddon we used to have) and as far as i know there is no workaround except analyzers providing custom knobs.

[RikkiGibson]

This issue was mentioned in a revision of #62641.

// TODO(https://github.com/dotnet/roslyn/issues/31916): The compiler currently doesn't support
// configuring diagnostic reporting on additional text files individually.
ImmutableArray<AnalyzerConfigOptionsResult> additionalFileAnalyzerOptions =
    additionalTextFiles.SelectAsArray(f => analyzerConfigSet.GetOptionsForSourcePath(f.Path));