Use 'is not null' instead of '!= null' in Newtonsoft converter #537
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Vogen does not follow best practices for null checks. Instead of using the "is" operator, it is using equality operators. This sometimes causes issues when a class has overloaded the equality operators.
Consider this code:
When using the Newtonsoft converter, the generated code by Vogen looks like:
The problem with this generated code is that Vogen uses != instead of not null, and so the compiler is unable to determine which operator to call. If we look at the metadata for the class LinuxAbsoluteFilename, since Vogen also adds its own operators, we see:
[DebuggerDisplay("Underlying type: System.String, Value = { _value }")] [DebuggerTypeProxy(typeof(LinuxAbsoluteFilenameDebugView))] [ExcludeFromCodeCoverage] [GeneratedCode("Vogen", "3.0.0.0")] [JsonConverter(typeof(LinuxAbsoluteFilenameSystemTextJsonConverter))] [TypeConverter(typeof(LinuxAbsoluteFilenameTypeConverter))] [ValueObject(typeof(String), Conversions.Default, null, Customizations.None, DeserializationStrictness.AllowValidAndKnownInstances, DebuggerAttributeGeneration.Default)] public class LinuxAbsoluteFilename: IAbsoluteFilename, IFilename, IEquatable<IAbsoluteFilename>, IEquatable<LinuxAbsoluteFilename>, IEquatable<String>, IComparable<LinuxAbsoluteFilename>, IComparable { public static Boolean operator ==(LinuxAbsoluteFilename? Left, IAbsoluteFilename? Right); public static Boolean operator ==(LinuxAbsoluteFilename left, String right); public static Boolean operator ==(String left, LinuxAbsoluteFilename right); public static Boolean operator ==(LinuxAbsoluteFilename left, LinuxAbsoluteFilename right); public static Boolean operator !=(String left, LinuxAbsoluteFilename right); public static Boolean operator !=(LinuxAbsoluteFilename left, String right); public static Boolean operator !=(LinuxAbsoluteFilename left, LinuxAbsoluteFilename right); public static Boolean operator !=(LinuxAbsoluteFilename? Left, IAbsoluteFilename? Right); }
So the compiler has three overloads to choose from:
public static Boolean operator !=(LinuxAbsoluteFilename left, String right); public static Boolean operator !=(LinuxAbsoluteFilename left, LinuxAbsoluteFilename right); public static Boolean operator !=(LinuxAbsoluteFilename? Left, IAbsoluteFilename? Right);
Since null is not strongly typed, the call is ambiguous. This can be prevented by using "is not null" instead.
But for now, this is causing a compile error for all such value objects.
This PR solves at least this issue for a specific case of Newtonsoft. I am not familiar enough with the code to know if there are similar issues elsewhere, so I have only fixed this specific place.