Increment on nullable always compiles to a conditional

[LucaFranceschini]

Increment on Nullable numbers always seems to compile to a branch, even when I would expect (maybe erroneously?) static flow analysis to successfully determine that the nullable actually contains a value. Example:

int? n = 0;
++n;

This gets compiled to:

.maxstack 2
.locals init (
[0] valuetype [System.Runtime]System.Nullable`1<int32>,
[1] valuetype [System.Runtime]System.Nullable`1<int32>
)

IL_0000: ldc.i4.0
IL_0001: newobj instance void valuetype [System.Runtime]System.Nullable`1<int32>::.ctor(!0)
IL_0006: stloc.0
IL_0007: ldloca.s 0
IL_0009: call instance bool valuetype [System.Runtime]System.Nullable`1<int32>::get_HasValue()
IL_000e: brtrue.s IL_001b

IL_0010: ldloca.s 1
IL_0012: initobj valuetype [System.Runtime]System.Nullable`1<int32>
IL_0018: ldloc.1
IL_0019: br.s IL_0029

IL_001b: ldloca.s 0
IL_001d: call instance !0 valuetype [System.Runtime]System.Nullable`1<int32>::GetValueOrDefault()
IL_0022: ldc.i4.1
IL_0023: add
IL_0024: newobj instance void valuetype [System.Runtime]System.Nullable`1<int32>::.ctor(!0)

IL_0029: pop
IL_002a: ret

So, it is still calling HasValue to ensure there is a value. This creates a branch that cannot really be executed, which then shows up in code coverage tools as incomplete branch coverage (see for instance coverlet-coverage/coverlet#1644).

Am I missing something?

[CyrusNajmabadi]

even when I would expect (maybe erroneously?) static flow analysis to successfully determine that the nullable actually contains a value

We have no such concept. We track of something has been assigned. We also have weak linting heuristics around if something could be null or not. However, we have a strong stance that that doesn't change codegen or semantics at all. It just affects if certain warnings are emitted.

[LucaFranceschini]

Ah, I thought flow analysis wasn't just for warnings but also for optimized codegen, at least in simple cases. Thank you for clarifying.

[CyrusNajmabadi]

which then shows up in code coverage tools as incomplete branch coverage

Seems an issue on their end.

[LucaFranceschini]

To me, it doesn't seem like a coverage tool's job to do static flow analysis. By the way this is not just about third-party tools, the same happens with VS built-in coverage tool. And even if the tool tried to, I guess it would get pretty hard in real world scenarios.

I mean... I know full branch coverage is not something you usually reach anyway, but this case seems so simple to catch that missing it is somewhat annoying :)

[333fred]

Consider if those two lines were split across different methods. No one could ultimately do that analysis. If the code will never run, maybe just remove the nullable.

[CyrusNajmabadi]

Note: i'm not opposed to the compiler having some local-only smarts where it might know accurately that a value is not null, and thus certain things could be elided. It might be some sort of optimization pass. But it seems very optional, and something that would be fine to never come.

Personally, i'd just like it to ease the burden on the jit, and generate more ideal IL/assembler.