Describe the bug

When sql is a const string whose declaration lives in a generated file, the SQL/parameter analysis appears to be skipped: only the call-site DAP018 is reported, and the @MinLogins/Wrong mismatch is missed.

Root cause: the analysis does run for const SQL — but its SQL-parse diagnostics (DAP214, etc.) are anchored at the constant's declaration, not the call site. When that declaration is in a generated file, the analyzer driver drops diagnostics there (generated-code suppression / <auto-generated>), so they never surface. For an inline literal the diagnostic is at the call site, so it shows normally — which is why the two cases looked different.

Where are you seeing this?

• Dapper 2.1.79
• Dapper.Advisor 1.0.52
• SQL Server (Microsoft.Data.SqlClient), <Dapper_SqlSyntax>SqlServer</Dapper_SqlSyntax>
• net10.0

To Reproduce

using Microsoft.Data.SqlClient;
using Dapper;

static class Q
{
    public const string GetUsers =
        "select Id from Users where LoginCount >= @MinLogins";

    // const reference: only DAP018 reported; @MinLogins/Wrong mismatch missed
    public static void ViaConst(SqlConnection c) =>
        c.Query<int>(GetUsers, new { Wrong = 1 });

    // inline literal: DAP214 correctly flags that @MinLogins has no supplied member
    public static void ViaLiteral(SqlConnection c) =>
        c.Query<int>("select Id from Users where LoginCount >= @MinLogins", new { Wrong = 1 });
}

(Reproduces when GetUsers is emitted into a generated file; an in-source const surfaces the diagnostic at its declaration.)

Expected behavior

For const SQL declared in generated code, the SQL-parse diagnostics should be re-homed onto the call-site sql argument so they stay visible — matching inline-literal behavior. Inline literals and constants in hand-written files keep their precise declaration-token location.

Additional context

In our codebase we expose .sql files as const string members via a source generator and pass those constants to Dapper instead of inline literals, so the SQL/parameter analysis never surfaced at our call sites and the DAP018 was misleading.