We just shipped v2 Core Framework 2.7.1, Analyzers 1.12.0, and Visual Studio adapter 2.5.8. This includes a few new assertion overloads, four new #Roslyn analyzers (and two new suppressors), and a handful of bug fixes.
I want to see if it's possible to replace runtime reflection in @xunit v3 with #Roslyn source generators (for better performance and to support NativeAOT), but I think I've already hit the first blocking point: no support for #FSharp? Only #CSharp and #VB? #dotnet
I have taken to doing something I normally don't like. The analyzer tests for @xunit are out-of-our-control slow because of the time spent to invoke #Roslyn and get the results from the analyzer.
So I've been combining tests that might've been separate, with "this line is bad, these lines are fine" by way of putting them all in one test, but only expecting a subset to trigger the diagnostic. 😣
The hardest part about writing #Roslyn analyzers is that you only think you know where all the edge cases are, but they let people type literally anything into an IDE these days. 😭😂
There is an unfortunate side-effect of writing #Roslyn#Analyzers with respect to compatibility.
The @xunit analyzers target Microsoft.CodeAnalysis 4.2.0 because that's what in VS 2022 17.2, which is currently still in LTS support.
CodeAnalysis 4.2.0 doesn't support C# 12. There are analyzers that are broken because of this, when used with C# 12 language features, and we can't fix them unless we're willing to throw away compatibility with everything before VS 2022 17.8.
And then as a bonus, it destroys some of the trivia along the way (like deleting a blank line that it shouldn't delete). (That part may be my fault, I haven't figured out whether I've actually fixed my other bug yet.)
I think I'd expect the call to ReplaceNode to have failed if it wasn't able to replace the node, but Roslyn isn't always helpful in that regard. Normally I'd dig into this in the debugger via the unit test, but the unit test passes. So I'm a bit stumped about what to do next. I'm not sure how to debug this indirectly (i.e., let it fail "for real" inside Visual Studio and debug it there), since it doesn't actually throw in a catchable way.
When creating a #csharp#roslyn analyzer, On the DiagnosticDescriptor, you can set a helpLinkUri property that will help folks understand the reasoning behind the analyzer.
Just so many little improvements in the latest #JetBrainsRider bring me so much joy. The way #Roslyn source generators and analyzers look in the solution view is one of them. #dotnet
In this post by @khalidabuhakmeh, learn how to debug generated sources, as well as the source generator itself – with the debugger, and with snapshot testing.
Having one of those "what the heck is wrong?!" moments.
I wrote a Roslyn analyzer. Tests work great.
I wrote the fixer for that diagnostic reported above. Test fails. Set breakpoints, and RegisterCodeFixesAsync never gets called, despite being set for the same descriptor. Same pattern I use with every other fixer, but this one is just silently... not doing anything.