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

Question: how to get .ToContextualProperty().Nullability the same for emitted properties as for a coded ones #84

Open
bessgeor opened this issue Jun 22, 2021 · 5 comments

Comments

@bessgeor
Copy link

bessgeor commented Jun 22, 2021

What am I trying to do?

Generate NRT-compatible classes using Reflection.Emit

What do I expect?

An emitted class having the same attributes as a coded one provides the same Nullability values for every property

What happens

Despite of having the very same attributes on emitted class, every emitted property is having the Unknown nullability while the coded ones are having the Nullable nullability.

I don't think this is a Namotion.Reflection bug, just trying to find someone to help me finding out what am I missing =)

Repro: https://github.com/bessgeor/namotion-reflection-emit-vs-roslyn (asserts the observed behavior).

@RicoSuter
Copy link
Owner

Oh this might be a hard one, NRT is based on quite some attribue-magic :-)
Maybe this blog post helps?
https://blog.rsuter.com/the-output-of-nullable-reference-types-and-how-to-reflect-it/

@bessgeor
Copy link
Author

bessgeor commented Jul 1, 2021

Thank you for the great article, it has helped alot to understand the actual effect of NRT annotations.
The fun thing is, if the assertions on the attributes are correct, they match between the written and generated classes, from the field level to the assembly level (module and assembly levels are checked against attributes containing a "Null" in their names only, which is the most error-prone assertion, would check it tomorrow). But the Nullability is different.

You may check out the repro if you'd like (one file, 174 LoC including the emit part). I guess I'm missing something and I would re-check asm and module attributes, but if there's nothing, I'm stuck.

Thank you :)

@RicoSuter
Copy link
Owner

RicoSuter commented Jul 2, 2021

Do you also generate the attribute classes directly in the assembly with the right namespace (ie not using them from another lib)?

@bessgeor
Copy link
Author

bessgeor commented Jul 2, 2021

I take them from the tests assembly, actually. Does this matter? I thought only attribute type shortname and parameters are important. Would try to emit them too and check it this way, thanks :)

@RicoSuter
Copy link
Owner

RicoSuter commented Jul 2, 2021

Not sure but roslyn generates them per assembly I think.

As a reference i'd use sharplab and try to generate the same output (right side):
https://sharplab.io/#v2:EYLgtghglgdgNAExAagD4AEBMACAKgUwGcAXAWACgBvC7W7dAZnoEYAGAfmwDEB7H7SgHN8xANzZCI0QF8KNOo3oAWbACEIAJwAU6Np2AQAXnBatswAK6GAlNnm1q5e9lnlXQA==

I think Namotion.Reflection doesnt care whether the attribute is generated in the assembly or just referenced, not sure however if roslyn analyzers work as expected...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants