S3900: Fix issue message for constructors

[zsolt-kolbay-sonarsource]

Task 12 of #6997

[antonioaversa]

LGTM

As discussed offline, I wonder whether this change is really needed.
I understand that in principle this is required to align the new implementation to the old one, which used to emit a different message for the specific scenario where the method parameter dereference is done in a this constructor initializer, or in a base constructor initialized.

However, this change requires using the syntactic model in the implementation of the rule, coupling (more) the rule to the underlying language, whereas the previous check was at symbolic level and it was quite clean (SemanticModel.GetDeclaredSymbol(Node).IsConstructor). Moreover the new implementation requires navigating the AST upwards, which is not ideal.

So I would challenge the need for this change.

[pavel-mikula-sonarsource]

LGTM, please address the comments before merging

[pavel-mikula-sonarsource]

This simple single-line condition is not worth extracting. Embed it on the call site. It reads pretty fluently.

[pavel-mikula-sonarsource]

Suggested change

	static bool IsUsedInBaseConstructorCall(SyntaxNode node) =>
	node.FirstAncestorOrSelf<ConstructorInitializerSyntax>() != null;
	static bool IsUsedInBaseConstructorCall(SyntaxNode node) =>
	node.FirstAncestorOrSelf<ConstructorInitializerSyntax>() is not null;

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

100.0% Coverage
0.0% Duplication