-
Notifications
You must be signed in to change notification settings - Fork 32
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
Supress (even more) 'Non-nullable field must contain a non-null value when exiting constructor (CS8618)' #385
Comments
@smkanadl Thanks for the compliment. I'm not in favour of the attribute, for two reasons:
In your case nothing calls the I updated the suppressor to traverse into instance methods called from |
Hi, of course I am not a big fan of the attributes either, so I completely agree/understand your arguments. Is there a pre-release version to try out? |
You can find the NuGet packages in the build artifacts. I just tried that out and it works for a test project I made. |
Hi @manfred-brands, I gave that version a try and it works(*). The suppression of the nullable warnings works perfect in the IDE, but in the build I still get the warnings and I even get warnings for direct variable assignments in the I have the strong assumption, that it is related to the warning that I also get in the output: I looks like when actually running the build, the supressor crashes and none of the potential warnings are surpressed. I already did a run with diagnostic output, but it didn't give any more specific details or context from where the exception is thrown. It happens in a larger test project with ~80 fixtures and ~800 test cases. Is there any more data that I can provide or how can I help you to go forward? |
@smkanadl it is a pity that the exception doesn't actually say what the key is as that would give some indication where to look. I managed to reproduce your problem. The only Dictionary created in the Suppressor is the one of methods in the class. I assumed that the method names would be unique, but that is not the case when using parameter overloads. public void SomeMethod(int i);
public void SomeMethod(double d); This raises the complexity; I not only have to check the method name, but also its parameter types. I don't even think those are available at the level the suppressor runs as it requires potential conversions, e.g. when passing an I will have a look what I can do. |
Yeah, thats one of my typical problems when it comes to standard dotnet exceptions.
Sounds good, although the details themself not :-/. I really appreciate the effort you put in and hope you will find a solution! |
That one is working beautifully. And the overload detection code doesn't look too bad for me :-). Again, many thanks! PS: Is there a release date scheduled for 3.2? |
That depends on @mikkelbu |
Hi @smkanadl |
That would be a perfect fit into m time schedule! Thank you! |
@manfred-brands I tried the latest and it still works like a charm :-) |
I've just merged the PR. I'll try to make a release tonight CET aka in 4-5 hours. |
I started to migrate a larger codebase towards nullable reference types and the Analyzers are of great use. Many thanks for the effort so far!
The analyzer is already capable of suppressing simple cases where the variable is assigned within the
SetUp()
method explicitly (CasesomeVariable
).I was wondering if it is possible to detect some more complex cases (Case
someVariableThatGetSetInACodeAnalysisDecoratedFunction
)? Of course it may not be a good idea to do extensive travelling of the AST to find an assignment deep down in some function called bySetUp()
,Instead, I thought it might be possible to take advantage of the
System.Diagnostics.CodeAnalysis
attributes. In this case e.g.MemberNotNull
. In such a case it would only the functions that are called directly called bySetUp()
needed to be analyzed and checked for theMemberNotNull
attribute. Then the attributes argument has to be matched against the member variables that are causing warnings to find one that could be suppressed.What are your thoughts on this?
The text was updated successfully, but these errors were encountered: