-
Notifications
You must be signed in to change notification settings - Fork 4.6k
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
Address diagnostic issues in runtime incremental source generators #92509
Comments
Tagging subscribers to this area: @dotnet/area-extensions-configuration Issue DetailsPlaceholder to address related feedback in #89587.
|
I'd mentioned this to @sharwell last week, and he wasn't sure why the diagnostics we're outputting in this way wouldn't be suppressible with a pragma. He suggested it might be a Roslyn bug. |
I think that bug is dotnet/roslyn#68291 based on my discussions with @eiriktsarpalis. I think there's some concern that there might not be a safe way for incremental generators to emit diagnostics at all. |
We understand that this change is a regression from 7.0 for some generators, but we haven't been able to identify a case where a user would have suppressed a diagnostic in source. @eiriktsarpalis Still need to prototype a solution to this. Depending on what that looks like we could service it if someone is blocked by this. Workaround: NoWarn at the project level. |
It seems that something deeper is at play here. I tried fixing the issue by removing the trimming logic for |
Actually, disregard the above. The unit test I added is actually incorrect because it relied on the assumption that suppressing the issue in source would make it go away from the list of diagnostics reported by the |
Just FYI we ran into this here: https://github.com/open-telemetry/opentelemetry-dotnet/pull/5520/files#r1556221048 |
Do we know who owns the next "action" here? Is this a Roslyn issue? Or a problem with our source generators? It would be really great if this could be addressed in .NET 9. This issue really affects the dev experience using the Configuration Binder source generator. There are so many places where libraries use Options classes that have "extra properties" on them that aren't expected to be configured using the configuration, but instead set through code. In every instance of that, we need to globally suppress cc @jasonmalinowski (who is assigned the linked Roslyn issue) |
The issue fundamentally is that diagnostic instances pointing to |
@jaredpar - is this on the radar of getting addressed in Roslyn in the .NET 9 timeframe? |
@eerhardt is there a roslyn issue you're referring to? |
I think it's dotnet/roslyn#68291 based on the above discussion. But @eiriktsarpalis and/or @ericstj would need to confirm. The uber scenario I'm interested in having work is described in #100785. You can't suppress |
Yes. Effectively, with incremental source generators as they exist today, you can choose to either: The feedback thus far has then been "well, source generators probably shouldn't be raising diagnostics... duplicate the relevant checking into separate analyzers". |
Addressing dotnet/roslyn#68291 would fix Taking a step back, it would be worth pointing out that the issue stems from the fact that diagnostics in generators can only be reported in the final |
When testing the configuration binder source generator we discovered that the way the runtime source generators emit diagnostics is not suppressible in source. This is a regression from previous releases (see attached sample) however we've yet to scenario where a user would have a pragma suppression for one of these existing diagnostics - most are errors or informational.
See attached project: generatorWarnings.zip
We also discovered that even in previous releases, when a warning is praga suppressed the IDE analyzer flags the suppression as unnecessary.
We also discovered that in 8.0, the diagnostics (at least in Regex generator) no longer seem to honor .editorconfig severity setting.
Related: dotnet/roslyn#68291
CC @eiriktsarpalis, @stephentoub
The text was updated successfully, but these errors were encountered: