Open stephentoub opened 3 weeks ago
Tagging subscribers to this area: @dotnet/area-system-text-json, @gregsdennis See info in area-owners.md if you want to be subscribed.
This happens because the source generator will attempt to source generate for every type that is found within the transitive closure of JsonSerializable
types, even if those types are only defined on properties that define custom converters:
// A JsonTypeInfo<Bar> has been generated even if it isn't being used by Foo
Console.WriteLine(JsonSerializer.Serialize(new Bar("Value"), MyContext.Default.Bar)); // {"Value":"Value"}
class Foo
{
[JsonConverter(typeof(CustomBarConverter))]
public Bar? PropertyWithCustomConverter { get; set; }
// Serializes Bar as a plain old string
public class CustomBarConverter : JsonConverter<Bar>
{
public override Bar Read(ref Utf8JsonReader reader, Type typeToConvert, JsonSerializerOptions options)
=> new Bar(reader.GetString()!);
public override void Write(Utf8JsonWriter writer, Bar value, JsonSerializerOptions options) =>
writer.WriteStringValue(value.Value);
}
}
record Bar(string Value);
[JsonSerializable(typeof(Foo))]
partial class MyContext : JsonSerializerContext;
I don't think we could change this today without incurring breaking changes.
How can trimmer warnings be suppressed just in the generated files? Should the source generator be suppressing them with pragmas? Otherwise, it seems you need to suppress them project-wide.
Pragma suppressions won't prevent the linker from emitting warnings when it encounters unsafe APIs. The generated code must be annotated with attributes.
Then what do you recommend? You moved this to future, but that's effectively saying such warnings need to be suppressed at the project level, which then defeats the purpose of such warnings and makes it near impossible to guarantee linker safety.
but that's effectively saying such warnings need to be suppressed at the project level
I don't believe either pragma suppressions or project level suppressions at the library will prevent the same warnings from being surfaced when running dotnet publish
. Suppressions must be made using attributes. @vitek-karas should be able to confirm this.
Then what do you recommend?
I can't think of anything that doesn't involve introducing new API. An ad hoc fix would involve just disabling generation for exception -- the code that it does generate today by default won't work since it has a number of already unsupported property types.
Pragma suppressions only work on analyzer. That said, if the generated code is never used, then trimmer or AOT will not produce warnings on it since they'll get rid of it first. So if the discussion is only around the case where the source generator produces code which is never used, pragma suppressions should be enough.
There's nothing really like "project level suppressions" - even if you suppress them via NoWarn
, if it's in the library, the final app will show them again (because trimmer runs on all IL globally). What is in theory possible is injecting suppression attributes via XML trimmer files, but that's not something we want to do if at all possible.
You can suppress the warnings on the app level via NoWarn
, just like any other warning, and that will work for all sources (analyzer, trimmer, AOT).
@sbomer
Description
In the repo below,
Exception
should not be serialized as it's defined, but rather only via the ExceptionConverter that treats it as a string. However, the source generator is emitting code to handle all of the properties on Exception. While this is unnecessary code, it also results in trimmer warnings about members of Exception that aren't safe to serialized.Reproduction Steps
Expected behavior
Code emitted for Exception related to its converter.
Actual behavior
Emits this:
Regression?
n/a
Known Workarounds
n/a
Configuration
.NET 9
Other information
No response