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

Roslyn merged a new analyzer API, DiagnosticSuppressor, that allow programatic suppression of warnings. The pull request can be seen here: Add new analyzer API (DiagnosticSuppressor) to allow programmatic sup… by mavasani · Pull Request #36067 · dotnet/roslyn · GitHub. It closes an issue that was open specifically about Unity’s SerializeField: Programmatic suppression of warnings · Issue #30172 · dotnet/roslyn · GitHub.

It looks like now Unity just needs to update its compiler version and implement a DiagnosticSuppressor to suppress CS0649. A new version of Roslyn is probably not released yet since this was merged yesterday, but I thought I should let you guys know.

And please add this to 2018 LTS!

30 Likes

+1 on this one!

Especially +1 for addition to LTS versions.

6 Likes

+1 for 2018 LTS.

I’ve been waiting for this fix. Hopefully it will be included in Unity soon.

4 Likes

2018 LTS please!

1 Like

Definitely +1 and yes 2018 LTS please!

1 Like

Yup!

This was made very much with the problem Unity had in mind. Pinging @JoshPeterson , @joncham and @LeonhardP as they were the people responding in the original thread . Will you be implementing this feature in the engine?

I’m not quite sure how this works, but I assume that this won’t land in LTS - it requires updating the Roslyn version, which doesn’t really sound very LTS-y.

7 Likes

+1

+5!

+6

Can this thread get a reply from Unity. This is one of biggest annoyance I’ve ever dealt with - needing to “decorate” my code with dumb #pragma statements.

3 Likes

+1

[SerializeField]
private Thing thing = default;

Until we get this, use the default keyword to explicitly initialize the field with a default value. The requested feature would allow us to skip this as well, but until then, it’s definitely better than pragma statements.

2 Likes

+1

my 400+ 0649 warnings will go away for good.

From the descriptions, I would say I want this. Would this be something that only Unity can add to the compiler or would it be possible for users to modify their local settings? If possible, we could start testing this.

We need to have a compiler which supports this feature.
The feature was merged into one of Roslyn’s feature branches on the 19th of June, and was merged from there into Roslyn’s master branch. The last Roslyn release was on the 21th of May. So unless Unity’s pulling Roslyn directly from Github instead of using official releases, it’ll be a while until this will be available in Unity.

4 Likes

+1 and 2017 LTS please.

I appreciate the solution at the root cause.

Otherwise, using the default assignment causes some compilers in IDEs, like JetBrains Rider, to warn that a variable was redundantly assigned the default value.

1 Like

I’m not sure if it can also be addressed with the Roslyn update, but I often see Visual Studio or ReSharper recommendations to convert simple Properties (that just return field values) to auto-properties even when the field has the [SerializeField] attribute.

      [SerializeField]
      private string descriptor;

      public string Descriptor => this.descriptor;

That recommendation is desired when dealing with a regular field, however fields that have the [SerializeField] attribute must not be converted to an auto-property. Doing so would remove the field from the Inspector.

I would love to see this recommendation suppressed when the property is associated with a field marked with [SerializeField].

That’s not something that can be done on Unity’s side, it has to happen on Jetbrain’s side. It’s already an issue on their Github, so they’re aware of it.

Thing is, this works:

[field: Serializefield]
public string Descriptor { get; private set; }

Though the result gives a garbled look in the inspector. So it’s not completely wrong to convert that property, given that you’re on a Unity version that supports attributes targeting backing fields (C# 7+)