Suggestion to Include Criteria for Identifying Generated Code in AnalysisContext.ConfigureGeneratedCodeAnalysis() Documentation
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 68/100
- Issue type
- Documentation
- Clarity
- Clearly specified
- Activity status
- Stale
- Tech stack
- csharp
- Domain
- documentation
Research direction
Start with dotnet/xml/Microsoft.CodeAnalysis.Diagnostics/AnalysisContext.xml and compare the ConfigureGeneratedCodeAnalysis() entry with GeneratedCodeUtilities.cs in the linked Roslyn source. Document the stated filename and header-comment criteria, then verify the resulting API documentation renders correctly and covers the reported .gen.cs case.
Written by the indexing model from the issue text.
Description
Type of issue
Missing information
Description
Dear .NET Documentation Team,
I am writing to provide feedback on the documentation for the AnalysisContext.ConfigureGeneratedCodeAnalysis() method. Currently, the documentation states:
Configure analysis mode of generated code for this analyzer. Non-configured analyzers will default to an appropriate default mode for generated code. It is recommended for the analyzer to invoke this API with the required GeneratedCodeAnalysisFlags setting.
However, the criteria for determining whether a piece of code is considered "generated code" are not specified in the documentation.
Upon reviewing the Roslyn source code, it appears that the following criteria are used to identify generated code:
https://github.com/dotnet/roslyn/blob/9951cebdc4f5581a0a06c1355f9f8c033ba0cb70/src/Compilers/Core/Portable/SourceGeneration/GeneratedCodeUtilities.cs
- The file name starts with any of the following strings:
- TemporaryGeneratedFile_
- The file name (excluding the extension) ends with any of the following strings:
- .designer
- .generated
- .g
- .g.i
- The comment at the beginning of the file contains any of the following strings:
- <autogenerated
- <auto-generated
Since these criteria are not documented, it is common to encounter cases where files with names that do not meet these criteria (e.g., .gen.cs) are unintentionally subjected to analysis. I believe it would be beneficial to include these criteria in the documentation to help users avoid such issues.
Thank you for considering this suggestion.
Page URL
Content source URL
- Dominant language
- No language data
- Stars
- 4.8k
- Forks
- 6.1k
- Avg merge
- 15h 30m
- Merged PRs (30d)
- 374
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from dotnet/docs
-
:watch: Not Triaged dotnet-framework/svc install-deployment/subsvc
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
:watch: Not Triaged
Difficulty 1/5 1-3 hours Newbie friendliness 84/100
-
:watch: Not Triaged dotnet-fundamentals/svc
Difficulty 1/5 Under an hour Newbie friendliness 82/100
-
dotnet-fundamentals/svc waiting-on-feedback
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
dotnet-csharp/svc lang-reference/subsvc
Difficulty 1/5 1-3 hours Newbie friendliness 70/100
Similar issues
-
user-reported
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Kong/developer.konghq.com#7316 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
HarperFast/skills#96 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
infinispan/infinispan#18150 ·
-
bug triage:deciding
Difficulty 1/5 Under an hour Newbie friendliness 88/100
open-telemetry/otel-arrow#4132 ·
-
Ecosystem: ClawMetry — the Qwen Code reader is now free and open source (follow-up to #9294 / #9338) Opencategory/integration priority/P3 scope/documentation status/ready-for-human type/feature-request
Difficulty 1/5 Under an hour Newbie friendliness 84/100