Fix false-positive DAP214 for {=XXX} literal-replacement syntax

[HarnageaGabriel]

Summary

Fixes a false-positive DAP214 (Variable @X is not declared and no corresponding parameter exists) when SQL uses the {=XXX} literal-replacement syntax, e.g.:

var result = await db.QueryAsync(
    "select Id, Name from Users where UserTypeId = {=Admin}",
    new { Admin = 123 });

Related issue: DapperLib/Dapper#2181

Root cause

Diagnosed by @andreasblueher in a comment on the issue:

the root of this issue is that GetParameters() only matches @param/:param/?param/$param via ParameterRegex — it does not recognize {=Admin} literal tokens.

SqlTools.GetParameters(string?) only scanned SQL with ParameterRegex (the @/:/?/$ prefixed forms), ignoring the already-existing LiteralTokens regex that matches {=XXX}. That method feeds SqlTools.GetUniqueParameters, which DapperAnalyzer.SharedGetParametersToInclude uses to build the filter of which anonymous-type/parameter-object members get included as known SQL parameters (ParameterMode.Filter).

Because Admin was invisible to that filter, it never made it into the ImmutableArray<SqlParameter> passed to TSqlProcessor.Execute. Separately, TSqlProcessor does rewrite {=Admin} to @Admin before AST parsing (via the same LiteralTokens regex) — so the parser sees a reference to @Admin, finds it isn't in the known-parameters set, and reports DAP214, even though the caller supplied it.

Fix

SqlTools.GetParameters now merges matches from both ParameterRegex and the existing LiteralTokens regex, so members referenced only via {=XXX} are correctly recognized as used/known parameters. No regex patterns were changed — only how their results are combined.

Test plan

• dotnet build — analyzer project builds clean
• Added [InlineData("select Id from Users where UserTypeId = {=Admin}", "Admin")] to SqlTests.DetectParameters
• Added DAP214.NoFalsePositive_Issue2181 regression test: verifies {=Admin} with a matching parameter member produces zero diagnostics
• dotnet test on test/Dapper.AOT.Test (net10.0): all 158 Verifiers diagnostic tests pass, including all other DAP21x cases (no regressions)
• Full test run across net48/net8.0/net10.0: only pre-existing, unrelated failure (DateOnlyTimeOnlyPostgreSqlTests.ReadDateOnly, a DateOnly→IConvertible cast issue in Postgres integration tests, unrelated to this change)

[mgravell]

Thanks for this — the root-cause analysis is spot on (and thanks @andreasblueher for the original diagnosis): TSqlProcessor rewrites {=Admin} to @Admin before parsing, but GetParameters never told the known-parameters set about it, so DAP214 fires on SQL that vanilla Dapper handles fine. Definitely want this fixed.

One catch, though: GetParameters feeds two consumers, and they need different answers. The analyzer's known-parameters set should absolutely include literal tokens (your fix). But the same result also drives the generator's include-filter — so with this change, a member referenced only via {=x} now gets emitted as a bound DbParameter, which is wrong: a literal token must be injected into the SQL text, never parameter-bound (and since Dapper.AOT doesn't implement literal injection yet, those call-sites shouldn't gain parameters at all). You can see this concretely by running the InterceptorTests golden suite on current main: the TsqlTips fixture picks up a // parameter map: a it shouldn't have. (Heads-up on that suite: it auto-rewrites the .output.* files and then asserts, so run it twice and review the git diff — a change there is a generated-output change.)

So the shape I'd suggest: keep the literal names out of the path the generator consumes, and include them only where the analyzer builds the set handed to TSqlProcessor — e.g. a GetParameters(sql, includeLiteralTokens: true) overload or a separate method, so the parameter-vs-literal distinction survives. That distinction becomes load-bearing later: literal injection is on the roadmap, and when it lands, {=x} members need to be recognized and routed differently from @x ones. A small extra test with both forms in one SQL (where A = @a and B = {=b}) would pin the split nicely.

Happy to help get this over the line whichever way suits you — if you'd like, I can push the adjustment onto your branch (if "allow edits by maintainers" is enabled) and you can review, or leave it with you with the notes above. Either way this is a good catch and I'd like to land it.

[mgravell]

Side note: the feature parity (the missing literal injection) is what I'm working on right now, so... timely.

[HarnageaGabriel]

Good catch, thanks for the detailed breakdown. Pushed a fix along exactly the lines you suggested: threaded an includeLiteralTokens flag through GetParameters/GetUniqueParameters/SharedGetParametersToInclude, defaulting to false. The analyzer's validation path (CommonParse, feeds DAP214) opts in with true; the generator's BuildParameterMap keeps the default false so literal-only members no longer leak into the bound-parameter list.

Added a regression case mixing @a and {=Admin} in the same query, plus an InterceptorTests golden fixture (LiteralTokens) confirming the generated parameter map only binds a. Ran the affected suite twice per the golden-file convention and diffed — clean, only a shows up now.

No need to push to the branch yourself, but appreciate the offer. Let me know if the shape looks right or if you'd rather see it split differently.

[mgravell]

merging with thanks