Add register method for analyzing embedded languages

[JamesNK]

Background and Motivation

There should be support for analyzing an embedded language with DiagnosticAnalyzer. For example, analyzers that inspect:

• Regex strings
• JSON strings
• Date/time format strings
• ASP.NET Core route strings

There are some analyzers for regex strings and JSON strings today that implement their own solution. They are currently editor only analyzers, and don't run during command line build (I'm not sure if that was intentional or a technical limitation)

ASP.NET Core route strings has its own solution that uses a lot of copy and paste (StringFormatAttribute detection and VirtualChar).

Providing a built-in, official solution would make it must easier for future embedded language analyzers to be written and to improve existing analyzers.

Proposed API

namespace Microsoft.CodeAnalysis.Diagnostics
{
     public class AnalysisContext
     {
+        public void RegisterEmbeddedLanguageAction(Action<EmbeddedLanguageAnalysisContext> action, ImmutableArray<string> stringFormats);
     }

+   public struct EmbeddedLanguageAnalysisContext
+   {
+       public CancellationToken CancellationToken { get; }
+       public Compilation Compilation { get; }
+       public ISymbol ContainingSymbol { get; }
+       public SemanticModel SemanticModel { get; }
+       public VirtualCharSequence Text { get; }
+   }

+   // Plus VirtualCharSequence & VirtualChar

Usage Examples

[DiagnosticAnalyzer(LanguageNames.CSharp)]
public class RoutePatternAnalyzer : DiagnosticAnalyzer
{
    public override void Initialize(AnalysisContext context)
    {
        context.ConfigureGeneratedCodeAnalysis(GeneratedCodeAnalysisFlags.None);
        context.EnableConcurrentExecution();

        context.RegisterEmbeddedLanguageAction(Analyze, ImmutableArray.Create("Route"));
    }

    public void Analyze(EmbeddedLanguageAnalysisContext context)
    {
        var tree = RoutePatternParser.TryParse(context.Text);
        if (tree == null)
        {
            continue;
        }

        foreach (var diag in tree.Diagnostics)
        {
            context.ReportDiagnostic(Diagnostic.Create(
                DiagnosticDescriptors.RoutePatternIssue,
                Location.Create(context.SemanticModel.SyntaxTree, diag.Span),
                DiagnosticDescriptors.RoutePatternIssue.DefaultSeverity,
                additionalLocations: null,
                properties: null,
                diag.Message));
        }
    }
}

Alternative Designs

Risks

[JamesNK]

cc @CyrusNajmabadi

[CyrusNajmabadi]

This is really up to compiler/analyzer to decide if htey want to do something here. I think it would be nice for there to be an official compiler API for understanding the contents of strings. However, it's not something i'm really interested in championing as my main use case is the IDE, and we have a story there. The desire to bring this stuff to things like the command-line experience is decidedly outside of that for me :)

@jaredpar for thoughts.

[jaredpar]

How does the embedded language detection work today? Essentially how do we map a given string literal and say "ah this is for embedded language X"? Or do we just throw every string at every embedded language analyzer and let them sort it out?

[CyrusNajmabadi]

We use the [StringSyntaxAttribute("lang-name")] attribute to make the determination. We also special case legacy Regex/Json apis (which predate that attribute), but that's not exposed/allowed for any other languages.

[jaredpar]

Does that attribute get placed on the API parameter? So basically developer defines

public void Method([StringsSyntaxAttribute("awesome-lang")] p)

Then calls like Method("blah") git passed to the analyzer associated with "awesome-lang"?

[CyrusNajmabadi]

@jaredpar Correct :) Also things like this.AnnotatedProperty = "blah" or [SomeAttr("blah")], etc. etc.

[mavasani]

@jaredpar Assigned to you for triage.