Type type = typeof(Program);
type = type.BaseType; // [CS8600] Converting null literal or possible null value to non-nullable type.
do
{
type = type.BaseType; // [CS8602] Dereference of a possibly null reference. + [CS8600] Converting null literal or possible null value to non-nullable type.
}
while(true);
In the program above I would expect the same warning from the compiler (BaseType can be null so it cannot be assigned to type variable). While in reality in the second case I get another error that seems wrong to me (type variable cannot be null by definition).
Is this some kind of an error in compiler, or the compiler is on the contrary is "extra smart" and figures out that I do try to possibly assign null to non-nullable variable and since it is only a warning, it will now show both warnings?
If I comment the first assignment, the result is the same.
The compiler is indeed "extra smart" in this case.
For the line type = type.BaseType; in the loop, It sees that you are assigning BaseType (possibly null) to a variable type that is not supposed to be null. This produces CS8600, for the same reason as the first instance of CS8600.
It also sees that the expression type in type.BaseType is possibly null. This is because the compiler can see that you just assigned a possibly-null thing to type. Therefore, type.BaseType is dereferencing a possibly-null thing, and might throw a NullReferenceException. This causes CS8602.
The "null state" of every variable is tracked throughout the method. For more information on how the compiler does null-tracking, see the documentation here. Here I have annotated the null-state of type at each line of the program:
Type type = typeof(Program);
// not null, because typeof(Program) never produces null
type = type.BaseType;
// maybe null, because BaseType is of type 'Type?'
do
{
// still maybe null here
type = type.BaseType;
// still maybe null here
}
while(true);
// not null, because this line is unreachable :)
The result is the same even when you remove the line type = type.BaseType; that is outside the loop, because it's a loop. Even if type will not be null in the first iteration, it is still possibly null in the second iteration.