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.
Problem Statement
TL;DR: Source Generators cannot depend on the output of other source generators
Syntax Trees added by source generators are not added to the
Compilation
passed to other source generators, and the execution order of several generators in the same assembly is non deterministic.This is a problem when generator A needs to do semantic analysis of types created by generator B. If no semantic analysis is required, this problem does not surface.
Solution
This PR introduces
CombinedGenerator
, which may containGeneratorStep
s, and accumulatively updates theCompilation
object introducing the syntax trees added by each step, in order for the next step to receive the updatedCompilation
including all previously added syntax trees.A
GeneratorStep
might also depend on Code Analysis artifacts other than source generated Syntax Trees, created by a previous step in the same execution, therefore this PR introduces a nice API to do just that.Additionally, the generation of static files (such as generated attributes, etc) which depend neither on syntactic nor semantic analysis is encapsulated in a nice API as well.
Why?
FluentNavigationGenerator
actually depends on the output ofUiContextConstructorGenerator
. In master, these are meshed together in the same class (the latter), and there is an ad-hoc trick to workaround the problem stated above with theCompilation
object.This PR formalizes that ad-hoc trick into a proper, nice to use API.
Both
UiContextConstructorGenerator
andFluentNavigationGenerator
have been refactored to this new API and are working as expected in this PR.But seriously, why?
Because I needed this in order to make
[AutoInterface]
work.