Add letter casing mismatch validation and start triggering SYSLIB1021

[mrek-msft]

Fix #52228

Adds test case listed in issue and add code which validates template arguments and possibly triggers SYSLIB1021 diagnostics which is already defined, and documented, but as far as I know there were no place triggering it before which was briefly mentioned in issue:

Note: SYSLIB1021 diagnostic descriptor is already merged on main, but it is not being triggered.

[Copilot]

Pull request overview

This PR implements validation for letter casing mismatches in LoggerMessage template parameters, addressing issue #52228. The change adds detection for inconsistent casing of the same template parameter (e.g., {par1} and {PAr1}) and triggers the previously defined but unused SYSLIB1021 diagnostic error.

Changes:

• Added ValidateTemplatesCasingConsistency method to detect case-insensitive template duplicates with different casing
• Added diagnostic emission when mixed casing is detected in template parameters
• Added test case MixedCasing that verifies the diagnostic is triggered for the scenario described in the issue

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
LoggerMessageGenerator.Parser.cs	Implements ValidateTemplatesCasingConsistency validation method and integrates it into the parsing flow to trigger SYSLIB1021 diagnostic
LoggerMessageGeneratorParserTests.cs	Adds test case verifying that mixed-casing template parameters (e.g., {par1} and {PAr1}) correctly trigger the SYSLIB1021 diagnostic

[Copilot]

Consider adding a test case for templates with the exact same casing appearing multiple times (e.g., Message = "{par1} {par1}"). This would help document whether such usage is allowed or should be flagged as an error. The current validation only checks for case mismatches, but doesn't validate whether having the same parameter multiple times is intentional.

Suggested change

	[Fact]
	[Fact]
	public async Task DuplicateTemplateNameSameCasing_IsAllowed()
	{
	IReadOnlyList<Diagnostic> diagnostics = await RunGenerator(@"
	partial class C
	{
	[LoggerMessage(EventId = 0, Level = LogLevel.Debug, Message = ""M1 {par1} {par1} {a}"")]
	static partial void M1(ILogger logger, int par1, int a);
	}
	");
	Assert.Empty(diagnostics);
	}
	[Fact]

[Copilot]

Grammar error in the comment: "does not contains" should be "does not contain".

Suggested change

	/// Validates that templates list does not contains templates with mixed casing like {hello} and {Hello}
	/// Validates that templates list does not contain templates with mixed casing like {hello} and {Hello}

[Copilot]

There is an unnecessary blank line before the closing brace. This violates the consistent style seen elsewhere in the codebase where closing braces immediately follow the last statement.

Suggested change

[tarekgh]

I think we won't need to do that after doing #124257. In this PR we allow same parameter names with different casing, but the important thing is the number of different parameters have to match the method parameters.

#124257 (comment)

cc @rosebyte

[mrek-msft]

I thought about case which I think we broke as part of #124257, I think SYSLIB1021 would handle it, but if we are OK with behavior described in my last comment and mark this regression as part of breaking change or if we mitigate it differently, I agree it is not very useful.

[tarekgh]

We allow case mismatch between the message parameters and the logging method parameters. I would say, let's keep the current behavior allowing different casing for the message parameters and document that in the breaking change. Usually if this is unintentional, users will get another diagnostic for parameter's count mismatch.