[Feature Request] Use new DiagnosticSuppressor API to suppress CS0649 on SerializeField

It's simply a bad design if it's by design. This statement found in the tracker has now been rendered false: "Unfortunately, there is no magic to fix this." Microsoft added this piece of "magic" primarily targeting Unity.

 

Is it true that you just want all Rider errors, warnings in Unity Console? That might get overwhelming, I guess. Why not just look at this list in Rider?
I can imaging on each build in Unity ask list errors-warnings from Rider and print those to Unity Console.
We can discuss it also in https://github.com/JetBrains/resharper-unity/issues

 

Sorry somehow missed your reply!

Would be nice to be able to run R# CLT inspectcode as a Roslyn analyzer argument with nice output of the high severity (errors) editorconfig rules violations to the Unity's Console preventing successful compilation.
I'm not sure I need this on every script recompilation though (wouldn't like to increase iteration time), perhaps it's worth calling it once per N compilations instead (I'm not sure inspectcode can track diff to quickly check only new code).

R# CLT are IDE independent and may be used both VS and Rider projects, on Win and OS X, adding a lot of nice code inspections in all possible setups.

Though I understand it's a custom third-party stuff from the Roslyn point of view and more likely it's not possible to run it like a NetCore analyzers since it's totally another kind of tool with own specific output.

Thus so far I just run it manually and manually process the output.

 

Has this been implemented yet? Visual Studio (building or starting the debugger) spews out CS0649 warnings in Unity 2020.1.0b8. The csc/mcs files I this still works for warnings spewed in the Editor console, but not in VS.

We used to use the fix mentioned by Eric below but it no longer works in 2020.1 (it seems the ProjectFileGenerator.ProjectFileGeneration event no longer fires):
https://developercommunity.visualstudio.com/content/problem/254578/cant-disable-warning-cs0649.html

 

nope

 

Hello, we should already suppress those kinds of warnings.

See our open source project on Github:
https://github.com/microsoft/Microsoft.Unity.Analyzers

And more specifically:
https://github.com/microsoft/Microsoft.Unity.Analyzers/blob/master/doc/USP0004.md

We already ship these analyzers in the box for both VS 2019 (16.4+) and VS for Mac 2019 (8.4+), required for properly supporting the DiagnosticSuppressor API.

Regards

 

@sailro - Here's the test case that seems to break it in Visual Studio:

* Do a "Build Solution" inside of VS.

After a slight delay, IntelliSense will start underlining all the CS0649 errors in the Text Editor window. Closing and reopening the source file doesn't get rid of the underlines. If I actually delete the line of code and re-paste it, *then* the underlined warning goes away, so something is definitely wrong there.

Note that the "Error List" never actually lists these warnings, but they still show up in the Text Editor/Code window which is very annoying/distracting as they should be ignored. So it seems like it's just a bug with the displaying of the underlined warnings in the Text Editor window as they also show up in the lower-left Errors/Warnings display inside the text editor even though the Error List shows 0 warnings.

And if you're wondering why one would want to do a Build Solution inside VS, it's because the Error List does not always seem to update properly and show errors in other files until a Build is done ... despite the Error List being set to "Entire Solution". So I end up seeing errors listed in Unity's Editor Console log if I Save-All in VS, while the Error List in VS is still empty until I do a "Build Solution". This seems like a different bug with VS as it seems to happen once or twice a day to me, but I can't reproduce it yet.

Using: Unity 2020.1.0b11 / VS 2019 v16.5.5

 

Hi @Ziflin, this is not something I repro when using VS2019 16.6.2. Any chance you could upgrade your VS installation ?

And one setting you can try to play with is:
Tools/Options/Tools for Unity/Disable the full build of projects -> true/false

Because Unity projects in Visual Studio are just a representation of what Unity builds, binaries built by Visual Studio are never used. Disabling building in Visual Studio makes some operations faster, like starting the debugger. However, perhaps in your case this setting affects how warnings are displayed.

Regards

 

@sailro Thanks! I should have upgraded VS 2019 to 16.6.2 first before posting as I cannot reproduce it now as I was just before upgrading.

However, now I get some new Unity Analyzer "Messages" in the Error List that I don't think I got before:

UNT0014 - "T is not a Unity Component"

This seemed to be caused by a helper extension method similar to:

Code (CSharp):

1.         public static T GetComponentExample<T>( GameObject go ) where T : MonoBehaviour
2.         {
3.             return go.GetComponent<T>();
4.         }
5.  

It seems that the analyzer is not checking that to see that 'T' is a constrained generic and checking the constraint.

I also seem to be getting a few new ID0051 "Private member X is unused" messages for private static methods that use the [MenuItem] attribute. I'm not sure if these worked before or I just missed seeing the issue, but they can at least be solved by making them public/internal.

I can add these to the GitHub issues for the Analyzer if that would help.

 

Nice if it's now working properly.

I think we already fixed your issues:

For MenuItem (I fixed this one today):
https://github.com/microsoft/Microsoft.Unity.Analyzers/issues/84

For the generic constraint check (This one will be in 16.7):
https://github.com/microsoft/Microsoft.Unity.Analyzers/issues/71

 

Awesome! The only other issue I've run into is the "IDE0031 Null check can be simplified" seems to conflict/war with "UNT0008 Unity objects should not use null propagation."

So if you have something like:

Code (CSharp):

1. var target = _target?.GetComponent<X>();

I get the UNT0008 warning, but when I convert it to:

Code (CSharp):

1. var target = ( _target != null ) ? _target.GetComponent<X>() : null;

I then get IDE0031 for "Null check can be simplified". Not sure if there's a way to disable IDE0031 project-wide or not.

Thanks again for the help, I swear this is the last one!

 

We should suppress `IDE0031` as well:

See
https://github.com/microsoft/Microsoft.Unity.Analyzers/blob/master/doc/USP0002.md

Tested here:
https://github.com/microsoft/Micros...UnityObjectNullHandlingSuppressorTests.cs#L46

But I think you found a bug (my two cents: this is related to those
parentheses for the condition).

 

Fixed here:
https://github.com/microsoft/Microsoft.Unity.Analyzers/issues/88

 

@sailro Great! It looks like the ()'s issue also applied to passing it into a method? As in:

Code (CSharp):

1. transform.SetParent( _area != null ? _area.transform : null );

Would have also caused the same issue?

 

I will fix all those cases in the PR. (this one is yet another one).

Syntax analysis is hard

 

Hehe! Thanks! Yeah, It seems like it'd pretty pretty tough to deal with so many cases for these things!

 

Is there a way for me to get these tools integrated with omnisharp for vscode?

 

You can use diagnostic analysers, but not diagnostic suppressors so far:

I opened this ticket for tracking:
https://github.com/OmniSharp/omnisharp-roslyn/issues/1711