Warning CS0649 not suppressed properly when field is marked as [SerializeField]

When scripting version is set to 4.x the warning CS0649 is not suppressed for private / protected fields marked with [SerializeField]

3 Likes

Is the behavior different with the .NET 3.5 Equivalent scripting runtime?

Yes, they’re completely ignored.

Thanks! It looks like we have a bug report on this issue now, so we will investigate it.

https://issuetracker.unity3d.com/product/unity/issues/guid/1080427/

3 Likes

As far as I remember, this matches the behavior as if you compile in Visual Studio. I find it useful that Unity spits out the CS0649 warning, as it matches VS. I prefer to write and compile in VS and having Unity and VS match warnings is beneficial to me.

Thank you for looking into the issue, but I don’t really agree with it being marked as By Design. I mean, yes; without the attribute, it absolutely should output the warning, but with it, the field can be edited through Inspector, so it no longer makes sense.

Using the attribute in a way which was intended makes it work as intended – but now also produces a warning which cannot be removed – because it’s not a mistake.

In another thread, I posted a few ways I thought of to suppress the warning, but none of it sounds entirely ideal.

It was a bit annoying seeing the squiggly lines in Visual Studio, but in the current beta, having 70 “warnings” outputted in the Console each time Unity compiles is on entirely different level.

Matching compile warnings are certainly beneficial, I agree, but if it turns one of Unity’s features into a warning By Design, I think I’d rather avoid seeing it.

9 Likes

@Racoon_7 It can be avoided by assigning default values to the properties.
But going through a ton of code simply to get rid of the 100+ warnings will be real pain.

Not sure why the heck it should be “By Design”. Obviosly Unity’s design is different. We’re not writing C# bussintheass applications here, please stick to your own enforced previously conventions.

4 Likes

Gonna second everyone else here, having this be “by design” is insane. You’re essentially saying that using the attribute in the intended way, as you show in the docs, should spam warnings.

What?

This really drags out a big, big annoyance with the issue tracker. Whenever something annoying is “by design”, it’s generally really aggravating for users that are affected by the issue. But there’s almost never an explanation for why it’s by design. Generally, you have pretty good reasons for not fixing an issue, which if spelled out would satisfy most people running into the issue - or at least give enough reasoning for them to let it lie. But when that isn’t written down, you end up with frustration (and forum rage) instead.

Whenever something is marked as either by design, or as “won’t fix”, there should really be a mandatory field where an explanation for why this isn’t a bug that will be fixed is written down. If you add a special field to the issue tracker to explain why something has the label it has (unless it’s “will be fixed”), it would be much easier for us to understand your intentions, and generally breed more confidence in the community that you’re taking our issues seriously.

Now I’m guessing that this time it’s just a miscommunication - since you replied to the thread - but I just have to assume. If you take the “by design” at face value (which you would do if you didn’t happen to read this thread), it seems directly incompetent.

20 Likes

Hello,

I responded in bug with reasoning of why issue was closed and workarounds. It didn’t make it to public issue tracker.

The new C# compiler (Roslyn) is correct in reporting the additional warnings. This is same as you would get in any C# project/code in VS. The mono C# compiler did not report them in past.

You can disable the warnings with pragmas:

#pragma warning disable 0649
// your code
#pragma warning restore 0649

Or disable it globally by adding a csc.rsp file to your project and adding command line switch to disable the warning: -nowarn:0649

Thanks,
Jonathan

8 Likes

But that would disable the actual useful warnings as well. Going through all source code and marking them as excluded is no solution. I might simply initialize them to default values instead, if that’s the case.

I wonder. Is there any code that performs filtering in native console (Editor native side)?
It would be much more useful to check if those fields are actually marked as [SerializeFields], then simply don’t output the message if it’s true.

Default console is now a broken toaster with all the warnings that will crop out.
(Send Messages in OnValidate when checking if object is a prefab, this one, multiscene setup warnings. ugh)

6 Likes

You really should, every time. This is what I meant earlier - when you don’t make replies to bugs public, you cause massive frustration in the community. For the specific person reporting the bug, they get a reason for why the bug was closed without a fix, but for the rest of the community, it’s just a big middle finger saying “deal with it”.
As a different example, here’s a bug I reported. I had a pretty pleasant back-and-forth with the QA team, and I got a satisfactory reason for why it won’t be supported. I’m happy. For the rest of the community, that page says “Undo is broken by design”.
This is a failure of communication, and it’s so easy for you to fix it! You have written the reason down somewhere, you literally just have to copy-paste it.

Also jeez louize this is not the correct thing to do. The compiler is wrong, since it doesn’t understand the semantics of the [SerializeField] attribute. The correct thing to do here is to go in and suppress this warning before it hits the console. Rider/Resharper does just that with the Unity plugin, I assume VS’/VS Code’s Unity plugin does that same? They should.

If developers follow the standard community guidelines, every single serializable field that doesn’t have a good reason to be public is marked as [SerializeField] private. We’ll be spammed with thousands and thousands of warnings for doing the correct thing. Your workarounds have major downsides - either turn the warning off (which is a bad idea, it’s a useful warning), or add thousands of #pragmas to projects that clutter everything up.

As @VergilUa is alluding to, the 2018 cycle is spamming down the console with crap we can’t do anything about to the point where it’s becoming near useless. It’s an important tool for us, and you’re essentially degrading it with every update to the engine.

24 Likes

I have added the informative text and the public issue tracker info will be updated with it shortly.

1 Like

No argument here. This is a problem and we need to solve it. Thanks for the clear words, we’re looking into this.

14 Likes

So, it won’t be fixed, am I right?

Should I start refactoring all my code base then?

Hm. Thank you for the information. “It’s not possible to fix this” sounds better than “we want it to be like this”.

What about Visual Studio Tools for Unity? Could it be fixed from their side? Or is it just “whatever the compiler spits out ends up in the console”?

@VergilUa – Thanks for the tip about initialising the fields with their default value. The IDE still complains (“Redundant initialization with a default value”), but thankfully the warning in Unity is gone.
Because this issue involved a bunch of packages from the Asset Store which I didn’t want to spend much time refactoring, I ended up “fixing” this “error” with a regular expression.

Since C# 7.1 you can do something like:

[SerializeField] float runSpeed = default; // → 0f
[SerializeField] Texture2D texture = default; // → null

So I think I replaced every field without an ‘equal’ sign on the same line (= unassigned)
\[SerializeField\]([^=]+?);
with
[SerializeField]\1 = default;
It helped me get rid of a few dozen warnings at once.

10 Likes

It’s not related to the tools, but rather an actual Unity’s native console.

I was able to ignore multiple warnings selectively, but, with a different, custom written console.
So it’s possible, just UT seems to be on the lazy side. Or, because console is C++, it might be hard for them to pull the attributes for the actual field. Who knows, without the source - it’s impossible to tell the reason.

As a result, I ended up disabling default console and using custom one instead. Though, Application.logMessageReceived isn’t as reliable as well. Sometimes it looses some messages sent in Editor.

Although, this is not a scalable solution, as people won’t be using same console setup. So it’s no go for distributable packages.

This warning message is definately should be ignored by default when console receives it.

I hadn’t thought of that. To be honest, that makes this a lot less severe than I first thought.

1 Like

Alas you cannot inialize fields this way on structs :

Assets/Scripts/...: error CS0573: '...': cannot have instance property or field initializers in structs```

So the problem remains : either lots of warnings are lots of pragmas for something done the expected way.
3 Likes

Hi all, Hi @joncham ,

is there really no way this can be revisited? I personally think the workarounds are not acceptable. This will lead to projects being cluttered by compiler warnings and serious issues will be overlooked. Initializing everything explicitly by the default value just moves the issue to an IDE warning that will have to be ignored globally, with the same result of poor code quality.

I was under the assumption that this warning was indeed reported by the compiler even before, but was filtered out by the Unity console for fields with the attribute [SerializeField]. At least that could still be done somehow, I am quite convinced. Of course we cannot expect the Unity team to modify the compiler for this, but there should be something possible on the Unity side of this.

I really would appreciate this to be tackled. Thank you very much for your effort!

12 Likes

I’d also like to see this problem fixed.
I can’t add much to the good points which have already been said in this thread… it’s just a toss-up between using the recommended way + OOP’s best practices, and making everything public to avoid an incorrect warning.

I imagine that after 2018.3 goes out of its beta stage, a couple more complaints about this will pop up since this is a problem which will likely be present in most mid to large-sized projects.
I just updated an Asset Store package and had to open twelve files just to slap #pragma (…) at the top. It makes absolute sense for a third-party code – and far from only that – not to expose all the variables, yet this encourages it, as it’s the simplest solution. The other option is to hide a useful warning in order to avoid a few false positives – and I don’t really think the ‘proper’ way to write a Unity component should contain a step such as: “2) Write a preprocessor directive to disable inevitable warnings”.

5 Likes