Check for the CollectionExpression syntax kind early in UseSearchValuesAnalyzer

[MihaZupan]

This appears to "resolve" the issue hit in https://github.com/dotnet/runtime/pull/100520 (failures after ingesting #7252)

The issue appears to be that this else block https://github.com/dotnet/roslyn-analyzers/blob/e4d7ea6a967631713630cb1cf02efa7dfc35a8aa/src/NetAnalyzers/CSharp/Microsoft.NetCore.Analyzers/Performance/CSharpUseSearchValues.cs#L115-L120 is now being called with the @"\/"u8 expression.

While this condition will return false during the IsConstantByteOrCharCollectionExpression check, semanticModel.GetOperation(expression) intermittently fails when building System.Formats.Tar (consistently succeeds every second build ?!?).

Filtering out the expression kind before the call to semanticModel.GetOperation appears to "fix" the issue, but I don't understand why GetOperation would be failing like this in the first place 😕 We already have analyzer tests for this pattern (property returning utf8 string literals) that are perfectly happy with the current code, so this appears to be something specific to runtime code somehow.

The failing call stack from https://github.com/dotnet/runtime/pull/100520:

SyntaxTree: C:\MihaZupan\runtime\src\libraries\System.Formats.Tar\src\System\Formats\Tar\TarHeader.Write.cs
SyntaxNode: pathNameBytes.LastIndexOfAny(PathInternal ... [InvocationExpressionSyntax]@[30810..30876) (554,26)-(554,92)
System.ArgumentException: Syntax node is not within syntax tree
at Microsoft.CodeAnalysis.CSharp.CSharpSemanticModel.CheckSyntaxNode(CSharpSyntaxNode syntax)
at Microsoft.CodeAnalysis.CSharp.CSharpSemanticModel.GetOperationCore(SyntaxNode node, CancellationToken cancellationToken)
at Microsoft.NetCore.CSharp.Analyzers.Performance.CSharpUseSearchValuesAnalyzer.IsConstantByteOrCharArrayCreationExpression(SemanticModel semanticModel, ExpressionSyntax expression, List`1 values, Int32& length)

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 66.66667% with 1 lines in your changes are missing coverage. Please review.

Project coverage is 96.48%. Comparing base (e4d7ea6) to head (5705f38).

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #7279 +/- ## ========================================== - Coverage 96.48% 96.48% -0.01% ========================================== Files 1443 1443 Lines 345375 345376 +1 Branches 11362 11363 +1 ========================================== - Hits 333222 333221 -1 - Misses 9273 9276 +3 + Partials 2880 2879 -1 ```

[stephentoub]

@CyrusNajmabadi, any idea what's going on here?

[CyrusNajmabadi]

Nope. It's a better question for @cston or @333fred

[333fred]

Do we have a dump of the failure?

[MihaZupan]

Here's a memory dump for a build of dotnet build .\src\libraries\System.Formats.Tar\src with a slightly modified analyzers build right after GetOperation throws: dump Let me know if some other info would be more useful