STJ: Can the code generator emit errors or only warnings?

[elgonzo]

This is more a question of curiosity and not really a problem nor a cry for help.

I stumbled over the STJ code gen warning SYSLIB1031 which in my opinion should be an error and not just a warning (it being a warning and affected explicit [JsonSerializable] annotations simply being ignored doesn't feel like the proper response). This made me wonder why SYSLIB1031 is a warning instead of an error. I tried randomly to coerce some error from the STJ code gen, but i never encountered anything else than warnings being emitted by the STJ code gen.

This leads me to asking this question here: Is the STJ code gen able to emit errors? (I am not talking about warnings being treated as errors, i am asking about actual errors.)

If STJ code gen is not emitting any errors ever, what is the reason behind the STJ code gen only emitting warnings, even for warnings (like SYSLIB1031) where there appears to be no plausible situation when ignoring such a warning would not lead to problems or where ignoring the warning would equate with parts of the code written by the programmer just being ignored?

(Side note: The reason why SYSLIB1031 being a warning rubs me the wrong way is because it's one thing for a warning to effectively be "What you wrote is problematic. If you insist on keeping that code , alright, you're the boss...", but it's an entirely different thing for a warning - like SYSLIB1031 - to be like "What you wrote is problematic. I am just going to pretend you didn't write that...".)

[huoyaoyuan]

@eiriktsarpalis
Generally if the code can work in some way, a warning is easier to deal with than error. You can always turn on WarningAsError for this warning.

[elgonzo]

Thanks for the response! If you allow me to follow up (and remember that i am just asking purely out of curiosity, so please don't feel urged to deal with my nagging here if you don't like...)

Generally if the code can work in some way, a warning is easier to deal with than error.

But this would be applicable to other situations that cause build/compiler errors as well, no? For example:

public class Foo
{
   public string SomeString;

   public Foo(int someInteger)
   {
       SomeString = someInteger;
       CallUndeclaredMethod();
   }
   
   public void DoSomething() {}
}

The line SomeString = someInteger; will cause a compiler error, as will the line CallUndeclaredMethod();. Why are these situations "worthy" of a build/compiler error and not just a warning? After all, the lines SomeString = someInteger; and CallUndeclaredMethod(); could be ignored and a warning emitted just like it happens with invalid [JsonSerializable(...)] lines -- the code would still work in some ways, just not in the expected and desired way.

To be clear: I am not arguing that compiler errors should be made warnings. But i hope this highlights the confusion i have with SYSLIB1031 being classified a warning and not an error.

You can always turn on WarningAsError for this warning.

I know, but that's not what my question is about.

[eiriktsarpalis]

My understanding is that it was made a warning because SYSLIB1031 will necessarily result in other compiler errors being emitted because of the duplicate properties. I agree with your reasoning that this should have been made an error, but I'm not sure if this wouldn't be considered a breaking change or worth the effort.

[elgonzo]

Thanks for satiating my curiosity ☺️

but I'm not sure if this wouldn't be considered a breaking change or worth the effort.

No, i am not advocating to change it. I agree with you that neither breaking established behavior nor the effort required would would be worth it.

My understanding is that it was made a warning because SYSLIB1031 will necessarily result in other compiler errors being emitted because of the duplicate properties.

This is not guaranteed -- applying conflicting [JsonSerializable] with types from different namespaces but with the same type name, or nested types of the same name from different parent classes, e.g.:

[JsonSerializable(typeof(A.Foo))]
[JsonSerializable(typeof(B.Foo))]

just produces SYSLIB1031 without other compiler errors. I would tend to see that as some exotic edge case, however... ;-)

[eiriktsarpalis]

Hmm, this doesn't seem to be the case (anymore?) -- applying conflicting [JsonSerializable] with types from different namespaces but with the same type name, or using duplicate TypeInfoPropertyNames just produces SYSLIB1031 without other compiler errors.

That's surprising -- my expectation is that the source generator would fail because it's trying to generate two different typeinfo property names with the same name hence resulting in compiler errors. Repro please?

[elgonzo]

Two repros, both with SYSLIB1031 warning but no compile error, the serializer will be throwing a NotSupportedException.

STJ vesion: 9.0.0-preview.3.24172.9

Repro with two classes of same name in different namespaces:

using System.Text.Json;
using System.Text.Json.Serialization;

namespace SYSLIB1031Demo
{
    class Program
    {
        public static void Main(string[] args)
        {
            var options = new JsonSerializerOptions()
            {
                TypeInfoResolver = MyContext.Default
            };

            var o = JsonSerializer.Deserialize<B.Foo>("{}", options);
        }
    }


    [JsonSerializable(typeof(A.Foo))]
    [JsonSerializable(typeof(B.Foo))]
    partial class MyContext : JsonSerializerContext
    { }
}


namespace A
{
    public record Foo(string? S);
}

namespace B
{
    public record Foo(string? S);
}

Repro with two nested classes of same name in different parent classes:

using System.Text.Json;
using System.Text.Json.Serialization;

namespace SYSLIB1031Demo
{
    class Program
    {
        public static void Main(string[] args)
        {
            var options = new JsonSerializerOptions()
            {
                TypeInfoResolver = MyContext.Default
            };

            var o = JsonSerializer.Deserialize<B.Foo>("{}", options);
        }
    }


    [JsonSerializable(typeof(A.Foo))]
    [JsonSerializable(typeof(B.Foo))]
    partial class MyContext : JsonSerializerContext
    { }


    public class A
    {
        public record Foo(string? S);
    }

    public class B
    {
        public record Foo(string? S);
    }
}

[elgonzo]

Using the [JsonSerializable] with duplicate TypeInfoPropertyName values will cause a compiler error, unless types specified for the [JsonSerializable] attributes share the same type name.

This will cause a compile error (EDIT: Correction. This will not cause a compile error either):

    [JsonSerializable(typeof(Foo), TypeInfoPropertyName = "x")]
    [JsonSerializable(typeof(Bar), TypeInfoPropertyName = "x")]

However, this will not cause a compile error:

    [JsonSerializable(typeof(A.Foo), TypeInfoPropertyName = "x")]
    [JsonSerializable(typeof(B.Foo), TypeInfoPropertyName = "x")]

I guess that's because the STJ code generator detects duplicate type names, thus ignoring the second [JsonSerializable] and not even attempting to generate any code for B.Foo, and thus also not attempting to generate code with duplicate type property names (even though the warning message mentions the duplicate type name "x" as specified by TypeInfoPropertyName).

By the way, i am using VS 2022, looking at the errors in VS' error list window.
Update: I also tested using dotnet instead of VS. No difference in behavior -- only SYSLIB1031 warnings, but no compile error.