search

unoplatform / Uno.CodeGen

A set of source generators for equality, immutability, ...
Other
90 stars 11 forks source link

Consider adding a GeneratedCode attribute (or reuse CompilerGenerated?) #128

Closed ndrwrbgs closed 3 weeks ago

ndrwrbgs commented 4 years ago

I'm submitting a...

- Feature request

Current behavior

Consider adding CompilerGeneratedAttribute (or another custom method) to generated methods.

Expected behavior

I have some developer-guiding unit tests that validate developer-written code follows some guidelines. The code generated by Uno is great, but I need to ignore it from the tests. I am going to work around this and add explicit understanding of GeneratedEquality to try to ignore those methods, but it would've been nice to have the methods noted first-hand as machine-generated methods (consider maybe for StyleCop rules?)

Minimal reproduction of the problem with instructions

N/A for non-bug

Environment

Nuget Package: Uno.CodeGen

Package Version(s): 1.32.0

Affected platform(s):
- [ ] iOS
- [ ] Android
- [ ] WebAssembly
- [x] Windows
- [ ] Build tasks

Visual Studio
- [ ] 2017 (version: )
- [ ] 2017 Preview (version: )
- [ ] for Mac (version: )
- [x] 2019

Relevant plugins
- [ ] Resharper (version: )
jeromelaban commented 4 years ago

Thanks for the suggestion! At this point, the reason those attributes are not added is that doing so makes them invisible to the debugger, and being able to debug the generated code so that it does not become a black box is a key goal of these generators.

The way we do this is generally to rely on the fact that the generated files are ending in .g.cs, and have roslyn analyzers ignore them.

ndrwrbgs commented 4 years ago

Thanks, implementation wise we could use a new attribute and enable the same functionality ;) unfortunately in reflection I can't tell the source file the code came from -- but again this really isn't vital so if the use case does not seem compelling to you I'd just close it.

jeromelaban commented 4 years ago

I see. You could probably still tell where the class comes from using the debugging symbols (e.g. using the sequence points from the ctor, if you have access to cecil), but it may be overkill for your scenario.

In some other generator that is not in this repo, we added the ability to inject arbitrary pragmas at the beginning of generated files, using ItemGroups provided by msbuild, but it's not available in these generators.

Let's keep this opened, though, the feature may be of interest.

ndrwrbgs commented 4 years ago

I didn't even think of utilizing the pdb data to figure such things out. I doubt the .NET Reflection would give me much on it, but yeah I bet Mono.Cecil would!