Old SE: Handle unsupported syntax gracefully

[martin-strecker-sonarsource]

Fixes #6766

The old SE engine throws NotSupportedException for a lot of pattern kinds:

• ParenthesizedPattern
• BinaryPattern
• UnaryPattern
• VarPattern
• RelationalPattern
• ListPattern
• SlicePattern

This PR fixes this by bypassing the patterns.

[martin-strecker-sonarsource]

@costin-zaharia-sonarsource or @pavel-mikula-sonarsource We got a report about an AD0001 in the old SE engine (ParenthesizedPattern not supported exception). This PR tries to fix this, by suppressing the exception: Ignore the patterns by returning the unmodified SE state). Now there are some tests failing that explicit test that the exception is thrown:

sonar-dotnet/analyzers/tests/SonarAnalyzer.UnitTest/CFG/Sonar/SonarControlFlowGraphTest.cs

Lines 4105 to 4142 in 6bc8c18

	public void Cfg_VarPattern_InSwitchExpression_IsNotSupported()
	{
	var exception = Assert.ThrowsException<NotSupportedException>(() => Build(@"string a = taintedString switch {var x => null};"));
	exception.Message.Should().Be("VarPattern");
	}
	[TestMethod]
	public void Cfg_VarPattern_InIf_IsNotSupported()
	{
	var exception = Assert.ThrowsException<NotSupportedException>(() => Build(@"if (tainted is var x) { }"));
	exception.Message.Should().Be("VarPattern");
	}
	[TestMethod]
	public void Cfg_NotPattern_InIf_IsNotSupported()
	{
	var exception = Assert.ThrowsException<NotSupportedException>(() => Build(@"if (tainted is not null) { }"));
	exception.Message.Should().Be("NotPattern");
	}
	[TestMethod]
	public void Cfg_AndPattern_InIf_IsNotSupported()
	{
	var exception = Assert.ThrowsException<NotSupportedException>(() => Build(@"if (tainted is int and > 0) { }"));
	exception.Message.Should().Be("AndPattern");
	}
	[TestMethod]
	public void Cfg_OrPattern_InIf_IsNotSupported()
	{
	var exception = Assert.ThrowsException<NotSupportedException>(() => Build(@"if (tainted is string or int) { }"));
	exception.Message.Should().Be("OrPattern");
	}

My suspicion is that it is possible to throw such exceptions in either CSharpControlFlowGraphBuilder or SonarExplodedGraph but I need some advice on how to do the suppression properly. Can you have a look, please?

[pavel-mikula-sonarsource]

The UTs that are failing becuase they expect an exception can be deleted now.

[pavel-mikula-sonarsource]

I took a deeper look and we're catching the wrong ghost.

We need a reproducer to start with. And fix that instead :/

[martin-strecker-sonarsource]

@pavel-mikula-sonarsource I added a reproducer now (see #6768 (comment)) (Spoiler: You were right about fishing in the wrong waters. The AD0001 was likely caused by a pattern in a switch statement).

I did not remove the other tests yet as I wanted to get your feedback about the reproducer first.

[pavel-mikula-sonarsource]

The repro and actual fix looks good. Requesting changes to move the card for final cleanup

[pavel-mikula-sonarsource]

Let's never throw

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[martin-strecker-sonarsource]

I double-checked and the latest changes are still fixing the AD0001 for Parenthesized and List patterns (all other patterns were supported already).

[pavel-mikula-sonarsource]

LGTM, no more value-less AD0001s 🎉