-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
CS1591 is fired on source generated code #54119
Comments
Related to #41171 |
Note this still occurs if the file correctly marks itself as generated via any of the heuristic methods. |
I don't see why the compiler shouldn't issue the warning? If the generated type is partial, then this could be a duplicate of #54103, and isn't specific to source generated files. Otherwise, then the compiler is correct about issuing a diagnostic IMO. |
I see there are other aspects than what #56419 solves. (e.g: dotnet/runtime#61379). But I think generator authors should produce a Not much convinced the compiler should special case generated code here. |
This was also reported regarding [JsonSerializable] (in #60533). We should either have the source generator produce documentation, or do a compiler-level solution. Will chat offline |
FWIW, I'm one of those odd birds that makes the compiler treat warnings like errors. Admittedly bit of a hardline approach, but muh code quality. Such draconian practices are duly rewarded by this breaking build. |
Can we get an answer as to whether this warning should respect *.generated.cs or <auto-generated />? I do not want generated code to pollute my build output with warnings. I do not have control over this code and therefore do not want style warnings like this XML warning to show up. As @nabond251 called out, this punishes folks that like to enforce code style using warnings as errors. |
On a project with the
/doc:
option enabled, the compiler will issue a warning on code that is coming from a generated file. (see dotnet/runtime#53275)A user can suppress the issue via a
.globalconfig
, but has no other recourse to fix the issue. Should we not fire CS1591 for generated code, or is it still a useful indicator to the user that types in their public API are going to have no documentation?The text was updated successfully, but these errors were encountered: