Fix StackOverflowException in RoutePatternAnalyzer

[JamesNK]

Fixes #48097

Change semantic model analysis to use a Stack<T> instead of recursion. This removes the possibility of running out of stack and causing a stack overflow in files with deeply nested node graphs.

[cston]

foreach (var child in current.ChildNodesAndTokens())

It looks like the analysis is only interested in tokens, so this could be replaced with:

foreach (var token in root.DescendantTokens()) { ... }

[JamesNK]

The code I added follows what the Regex analyzer does. I investigated why the regex analyzer doesn't use DecendantTokens. I think it could have, but the recently added FilteredSpans check wouldn't work with the helper method:

https://github.com/dotnet/roslyn/blob/4dcbb0bdb9f7630fec6ce81b311525ef974fd4b0/src/Features/Core/Portable/EmbeddedLanguages/RegularExpressions/LanguageServices/AbstractRegexDiagnosticAnalyzer.cs#L63-L64

It looks like FilteredSpans has only just been made public. aspnetcore probably won't update to bits with it until after .NET 8. I'd like to leave the method as is so using FilteredSpans in the future is possible.

Btw, what are filtered spans? I'm guessing it's an optimization, but I'd be interested if you could point me at more detail.

[cston]

Adding @mavasani for the question on filtered spans.

[mavasani]

FilterSpan is the new API added on analysis context types when computing diagnostics for lightbulb. This allows expensive analyzers to optimize their performance based on the span within the tree for which diagnostics are being computed. If the analyzer ignores this span, the analyzer driver will filter the reported diagnostics outside this span, there should be no functional impact of ignoring this filter span.

[JamesNK]

This analyzer is expensive. Do you recommend eventually using filter span like other analyzers are doing?

[mavasani]

Definitely - all SemanticModelAnalysisContext callbacks should respect the filter span. I plan to write a meta-analyzer in Microsoft.CodeAnalysis.Analyzers package to recommend the same. These analyzers are known to be the biggest beneficiaries of this API on lightbulb path.

[jaredpar]

I do not understand why DescendantTokens is in compatible with FilteredSpans. It can be implemented by passing down the predicate correct? Having every analyzer / generator out there build their own stack for navigating the tree to scan tokens is not the right solution.

@333fred

[JamesNK]

I see there is a DescendantTokens overload that takes a span: https://github.com/dotnet/roslyn/blob/252def9efa028af3f0562929b4b0e8a74dcd3124/src/Compilers/Core/Portable/Syntax/SyntaxNode.cs#L1049

It looks like the overload checks span overlaps.

I think the below would work (assuming FilterSpan was available):

foreach (var item in root.DescendantTokens(context.FilterSpan))
{
    cancellationToken.ThrowIfCancellationRequested();

    AnalyzeToken(context, routeUsageCache, item, cancellationToken);
}

DescendantTokens allocates an enumerator, but this method was allocating a collection before anyway. I'll switch the PR to use it and we can add FilterSpan when it's available.