Skip to content
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

Use .NET source generators to generate strongly-typed overloads #2015

Merged
merged 13 commits into from
May 16, 2024

Conversation

blairconrad
Copy link
Member

Closes #1804.

@blairconrad blairconrad marked this pull request as draft April 21, 2024 12:18
@blairconrad
Copy link
Member Author

Hey, @thomaslevesque. For your consideration. Of course there are more classes to convert, but I thought I'd give you a peek before I invested more hours. I am content with the changes relative using T4, but am also open to leaving T4 in the mix and/or exploring a proper templating solution.
Tell me what you think!

Copy link
Member

@thomaslevesque thomaslevesque left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, thanks @blairconrad!

Two remarks:

  • I see you used the original source generator model, rather than the newer "incremental" generators. In this case, I think it doesn't matter, because you don't have any syntax receiver that would trigger a regeneration on every keystroke.
  • I don't see the generated code in your PR. By default it's generated in the obj folder, which is excluded from source control. If we want to include the generated code in source control, we can specify the path where it's emitted with CompilerGeneratedFilesOutputPath.

@blairconrad
Copy link
Member Author

blairconrad commented Apr 21, 2024

I see you used the original source generator model, rather than the newer "incremental" generators. In this case, I think it doesn't matter, because you don't have any syntax receiver that would trigger a regeneration on every keystroke.

Ah! I can look at the incremental one. I just used the first guidance I found.

I don't see the generated code in your PR. By default it's generated in the obj folder, which is excluded from source control. If we want to include the generated code in source control, we can specify the path where it's emitted with CompilerGeneratedFilesOutputPath.

I will explore this!

@blairconrad
Copy link
Member Author

Sorry @thomaslevesque. I rebased. I even put some commits in before the originals.

Copy link
Member

@thomaslevesque thomaslevesque left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @blairconrad! Looks good in general. I do have a few comments.
To be honest, after the first 2 "Use source generator" commits, I only gave the next ones a very cursory review, but I like the approach you took.

Directory.Build.props Outdated Show resolved Hide resolved
src/FakeItEasy/FakeItEasy.csproj Outdated Show resolved Hide resolved
src/FakeItEasy/FakeItEasy.csproj Outdated Show resolved Hide resolved
tools/CodeGen/ExceptionThrowerGenerator.cs Outdated Show resolved Hide resolved
@blairconrad blairconrad marked this pull request as ready for review May 15, 2024 01:59
thomaslevesque
thomaslevesque previously approved these changes May 16, 2024
Copy link
Member

@thomaslevesque thomaslevesque left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @blairconrad, looks good to me! Just squash the fixups, and I'll merge

Generated source files don't pay attention to the .editorconfig file,
as described in [.editorconfig diagnostic suppressions don't apply to
source-generated files](dotnet/roslyn#47384),
but they do respect a .globalconfig file.
If we add a new project in a surprise subdirectory, as we recently did
for recipes, and will soon add a source generator to tools, then we
won't have to manually suppress the warning.
ValueTask-related overloads (coming soon) will not always apply
@blairconrad
Copy link
Member Author

blairconrad commented May 16, 2024

@thomaslevesque, I squashed. While I was there I dropped c0e6a1c "Define constant LACKS_VALUETASK to exclude ValueTask-related functionality", as we discussed. With that removal, 445e88c "Use pre-.NET Standard 2.1 framework detection for FakeItEasy" didn't do anything for us, so I dropped that commit as well.

While I was at it, I distributed

472c236 "Use source generator to create strongly-typed overload for FakeItEasy.Extensions.ValueTask" amongst 3 other commits:

  • 7ac2841 "Generate strongly-typed overloads only when base type exists" (which is effectively a new (or shifted back in time) commit)
  • e1291db "Use source generator to create ValueTaskAsyncReturnValueConfigurationExtensions.StronglyTyped.cs" (pre-existing)
  • 4f93dd8 "Use source generator to create ValueTaskReturnValueConfigurationExtensions.StronglyTyped.cs" (pre-existing)

I think this clears stuff up. Thanks for the great suggestions. I had a ball working on this PR!

Copy link
Member

@thomaslevesque thomaslevesque left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is great, thanks!

@thomaslevesque thomaslevesque merged commit d78c11f into FakeItEasy:master May 16, 2024
4 checks passed
@blairconrad
Copy link
Member Author

Thank you, @thomaslevesque!

@blairconrad blairconrad deleted the 1804-source-generators branch May 16, 2024 13:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Consider using .NET 5.0 source generators to generate strongly-typed overloads
2 participants