You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is currently non-trivial to generate source for a partial method.
Rationale
Currently if you want to generate code for a partial method, say:
[SomeAttribute]publicpartialvoidMyMethod();
You need to first regenerate all the context that exists for MyMethod. That is, you must
generate partial declarations for all parent types in the hierarchy
generate the containing namespace declaration
generate valid usings for all type parameters -or- replace them with fully qualified members
this may also involve resolving conflicts between types, if any exist
etc
This is relatively non-trivial to do and is likely not going to be very future proof as the scenarios that need to be handled are expanded in the future. e.g. C# 9 is adding records, which are a new TypeDeclarationSyntax kind.
Proposal
A set of APIs should be provided that make it easier to build the appropriate context for the generated source code. These should be maintained in sync with the compiler so that new types (like RecordDeclarationSyntax) are handled where relevant.
Other Thoughts
Building the source as a string exposes a few additional issues such as risking introducing warnings or errors.
If you, for example, try to handle the above yourself and take the existing using directives, namespace declarations and type declarations and use the existing source string, then you might introduce duplicate using directives that conflict with the namespaces you need in your generated code.
However, if you decide to generate everything using fully qualified names, you will greatly hinder readability of your generated code which can hinder debuggability. Likewise you end up needing to track things like indentation levels and other trivia to help handle these scenarios and provide a good all around experience.
Using the SyntaxFactory to generate the code, even if it is to ultimately just convert it to a string that the compiler then parses, can help simplify a good bit of this. However, it is very easy to forget to insert various bits like needed trivia, and that you may need to call .NormalizeWhitespace() to handle this.
The text was updated successfully, but these errors were encountered:
Note: SyntaxGenerator handles all these cases. But is defined at the Workspace layer. @jaredpar for thoughts on how we can take a lot of the code-gen smarts we've built over the last 10 years and make them available to SG authors.
sharwell
changed the title
[Source Generators] Make it easier to generate code for a partial method
Make it easier to generate code for a partial method
Sep 21, 2020
Issue
It is currently non-trivial to generate source for a partial method.
Rationale
Currently if you want to generate code for a partial method, say:
You need to first regenerate all the context that exists for
MyMethod
. That is, you mustpartial
declarations for all parent types in the hierarchyThis is relatively non-trivial to do and is likely not going to be very future proof as the scenarios that need to be handled are expanded in the future. e.g. C# 9 is adding
records
, which are a newTypeDeclarationSyntax
kind.Proposal
A set of APIs should be provided that make it easier to build the appropriate context for the generated source code. These should be maintained in sync with the compiler so that new types (like
RecordDeclarationSyntax
) are handled where relevant.Other Thoughts
Building the source as a string exposes a few additional issues such as risking introducing warnings or errors.
If you, for example, try to handle the above yourself and take the existing
using directives
,namespace declarations
andtype declarations
and use the existing source string, then you might introduce duplicateusing directives
that conflict with the namespaces you need in your generated code.However, if you decide to generate everything using fully qualified names, you will greatly hinder readability of your generated code which can hinder debuggability. Likewise you end up needing to track things like indentation levels and other trivia to help handle these scenarios and provide a good all around experience.
Using the
SyntaxFactory
to generate the code, even if it is to ultimately just convert it to a string that the compiler then parses, can help simplify a good bit of this. However, it is very easy to forget to insert various bits like needed trivia, and that you may need to call.NormalizeWhitespace()
to handle this.The text was updated successfully, but these errors were encountered: