What's new in Unity 6? Overview of release updates and source code issues

V3005. The 'this.defaultHasBeenPrevented' variable is assigned to itself. EventDebuggerTrace.cs 42.

For some reason, the defaultHasBeenPrevented property is assigned to itself during initialization. Since the property has no setter, its value will never change again and will always have the default value of false.

You can fix the issue by adding a new parameter to the constructor to initialize the property.

V3095. The 'sprite' object was used before it was verified against null. Check lines: 310, 312. TextGeneratorParsing.cs 310.

The sprite variable is dereferenced before being checked for null:

m_CurrentSpriteAsset = sprite.textAsset as SpriteAsset;
m_SpriteIndex = (int)sprite.glyphIndex;

if (sprite == null)
  continue;

If sprite is indeed null, this inevitably leads to an exception. Perhaps the developers didn't consider the importance of operation order when adding string dereferencing to the method. To avoid the issue, you can move the dereferences under the null check:

if (sprite == null)
  continue;

m_CurrentSpriteAsset = sprite.textAsset as SpriteAsset;
m_SpriteIndex = (int)sprite.glyphIndex;

V3001. There are identical sub-expressions to the left and to the right of the '&&' operator. StyleSheetApplicator.cs 169.

The analyzer prompts that two identical expressions are executed using the && operator in one of the conditions:

if (((val1.handle.valueType == StyleValueType.Dimension) ||
     (val1.handle.valueType == StyleValueType.Float)) &&

    ((val1.handle.valueType == StyleValueType.Dimension) || 
     (val1.handle.valueType == StyleValueType.Float)))

Obviously, this is an error, and the fix is fairly straightforward. Look at the rest of the code—it performs similar operations consistently, first using val1 and then val2. For example, the condition that follows the one in question, consists of two similar checks:

else if ((val1.handle.valueType == StyleValueType.Enum)) &&
         (val2.handle.valueType == StyleValueType.Enum)

The only difference between the two is that the first one uses the val1 value, and the second one uses val2.

So, to fix the error, most likely, the devs need to replace all val1 with val2 in the repeated expression of the incorrect condition:

if (((val1.handle.valueType == StyleValueType.Dimension) ||
     (val1.handle.valueType == StyleValueType.Float)) &&

    ((val2.handle.valueType == StyleValueType.Dimension) || 
     (val2.handle.valueType == StyleValueType.Float)))

V3084. Anonymous function is used to unsubscribe from 'drawingMultiplayerBuildOptions' event. No handlers will be unsubscribed, as a separate delegate instance is created for each anonymous function declaration. EditorMultiplayerManager.bindings.cs 48.

This is a simple yet common error. Anonymous functions are used here for subscribing to and unsubscribing from an event. No matter how visually similar they are, these functions are still different objects. As a result, subscribing to an event is performed correctly, but unsubscribing fails.

One solution is to implement a full-fledged method instead of an anonymous function and use for both subscribing to/unsubscribing from the event.

V3001. There are identical sub-expressions 'previewUtility.lights[0].intensity != kDefaultIntensity' to the left and to the right of the '||' operator. AvatarPreview.cs 721.

The condition of the first if statement in the DoRenderPreview method consists of two identical subexpressions. This could be either a bug or simply redundant code left out due to oversight.

The implementation of the SetupPreviewLightingAndFx method, which uses not only previewUtility.lights[0] but also previewUtility.lights[1], hints at an error here.

So, this is how you can fix the error:

if (previewUtility.lights[0].intensity != kDefaultIntensity ||  
    previewUtility.lights[1].intensity != kDefaultIntensity)
{
  ....
}

V3025. Incorrect format. A different number of format items is expected while calling 'Format' function. Arguments not used: 3rd, 4th. UILayoutDebugger.cs 179.

Take a look at the second string.Format(....). Its format string (the first argument) has four slots for insertion. There are also four values passed for insertion (from the second to the fifth argument). The issue is that the slots contain only 0 and 1. As a result, only the first and second values are inserted, while the other two aren't used at all.

The corrected format string looks as follows:

var infoLine4_format = "<color=\"white\">" +
                       "Count of ZeroSize Element:{0} {1}%" +
                       " Count of Out of Root Element:{2} {3}%";

V3076. Comparison of 'f' with 'float.NaN' is meaningless. Use 'float.IsNaN()' method instead. PhysicsDebugWindowQueries.cs 87.

The error here relates to a not-so-obvious behavior. A comparison of two values that are equal to NaN is always false. So, as the analyzer prompts, we need to use float.IsNaN(f) instead of the f == float.NaN expression here.

V3197. The compared value inside the 'Object.Equals' override is converted to the 'SearchIndexEntry' type instead of 'SearchField' that contains the override. SearchItem.cs 634.

As the analyzer message states, in the first Equals method, the other parameter is incorrectly converted to the SearchIndexEntry type instead of SearchField. This results in the same method overload being invoked when Equals(l) is called later. However, if other is really of the SearchIndexEntry type, the code loops. So, the StackOverflowException will be thrown.

V3001. There are identical sub-expressions 'blackMinLevel < whiteMaxLevel' to the left and to the right of the '&&' operator. FrameDebuggerEventDetailsView.cs 364.

Again, we have the if statement with the condition consisting of two essentially identical expressions, which differ from each other only in the operand order. It should probably be something else instead of blackMinLevel in the second expression. A review of the surrounding code suggests that whiteLevel would be the most logical option. So, the fixed condition could look as follows:

if (blackMinLevel < whiteMaxLevel && whiteMaxLevel > whiteLevel)
{
  ....
}

V3042. Possible NullReferenceException. The '?.' and '.' operators are used for accessing members of the 'package' object. PackageSample.cs 102.

The check at the beginning of the method aimed to handle several cases at once:

• when package.upmReserved is null or an empty string;
• when package.resolvedPath is null or an empty string;
• when package is null.

However, it doesn't work correctly in most cases:

• if package is null, the NullReferenceException is thrown during dereferencing in the second subexpression of the check;
• if either package.upmReserved or package.resolvedPath is null or an empty string (but not both at once), the method doesn't exit as expected.

The developers may have used the operator && instead of || by mistake. So, the fixed check can look like this:

if (string.IsNullOrEmpty(package?.upmReserved) || 
    string.IsNullOrEmpty(package.resolvedPath))
{
  return Enumerable.Empty<Sample>();
}

V3145. Unsafe dereference of a WeakReference target. The object could have been garbage collected between checking 'IsAlive' and accessing the 'Target' property. TextGenerator.cs 140.

Despite the small amount of code, this is probably the most complex error in the article. Here are the reasons why:

1. Not everyone is familiar with the concept of WeakReference. The garbage collector can always remove the object referenced by a weak reference, despite the presence of that reference.
2. The WeakReference.IsAlive property enables you to check whether the object referenced by the weak reference still exists. However, this code ignores the possibility that the object can be cleaned up after passing the check but before the reference is dereferenced. As a result, the NullReferenceException may be thrown anyway.
3. One would assume that the lock operator could protect the object from the garbage collector. However, after reproducing the case, I learned that this wasn't true.

How can you protect yourself from the NullReferenceException, then? To avoid the NullReferenceException for sure, one needs to create a strong reference to the object. Then, the garbage collector will no longer delete it as long as the reference is relevant. In other words, create a simple local variable referring to the object and work with it. The safe method can look like this:

[RequiredByNativeCode]
internal static void InvalidateAll()
{
  lock (s_Instances)
  {
    foreach (var kvp in s_Instances)
    {
      WeakReference wr = kvp.Value;
      var target = wr.Target;

      If (target != null)
        (target as TextGenerator).Invalidate();     
     }
   }
}