Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Redo pubternalyzer with Roslyn Operations #21996
Redo pubternalyzer with Roslyn Operations #21996
Changes from 10 commits
cf3db52
8488397
f44a136
28d090c
e8dd3f5
80a452e
b730e30
3514b51
b27e8a7
2fcd169
f8c7056
68108d2
6d185f5
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we do similar analysis for generic type arguments of named types?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not at the moment. Do you have guidance on how to get the generic type arguments of an ITypeSymbol?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Scoping out to #22086, any guidance on this would be appreciated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems it would be better if you have different language specific analyzer assemblies for language specific code. Otherwise, your analyzer will cause a C# only solution to load all VB Roslyn assemblies and vice versa, which has an unnecessary assembly load overhead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good point - even if the assembly load overhead would only apply at build time...
The problem is that our analyzers package - Microsoft.EntityFrameworkCore.Analyzers - isn't typically referenced directly by user, but is brought in transitively as a dependency of Microsoft.EntityFrameworkCore. I know that ASP.NET also have a similar pattern, do you have any guidance on this, or any particular reason why the additional VB assembly load should be avoided?
If this is a big issue, we can drop the VB dependency altogether - it's only used to produce better/narrower diagnostic locations - the warnings themselves would still appear as we're using language-independent APIs here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Normally the way this would be done is that your analyzer package will have 3 assemblies - Core, C# specific and VB specific. Then the MSBuild/SDK machinery will ensure that C# projects have analyzer references to first two and VB projects to the first and third. This way if someone has a C# only solution or a VB only solution, they do not get penalized by loading non-required language Roslyn assemblies (which can be quite a few as most of Roslyn layers are divided the same way). @jmarolf can probably help with setting up/guiding on the SDK pieces.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh nice, was not aware of this... Any pointer to an analyzer package which does this would be sufficient!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jmarolf did this work for the
Microsoft.CodeAnalysis.NetAnalyzers
nuget package that we now insert into the .NET SDK. He can give pointers on how you can match his apporoach.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Scoping this out to #22085
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that it's slightly worse than this implies. Csc does not provide the VB assemblies, and vbc does not provide the C# assemblies. Command line use of an analyzer that references both will work if and only if the shared compiler server VBCSCompiler.exe is used, but that will occasionally fail to process a request and silently fall back to the language-specific executables, at which point the analyzers will silently fail to run.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you already know about these internal usages @AndriySvyryd, but just in case.