Repository navigation
JIT: (bug) inlining an instance method that never uses this drops the receiver null check #133713
Description
using System;
using System.Runtime.CompilerServices;
class Data { public int V; }
class Node { public int Get(Data d) => d.V; } // never touches 'this'
class P
{
[MethodImpl(MethodImplOptions.NoInlining | MethodImplOptions.AggressiveOptimization)]
static int Foo(Data d, Node n) => n.Get(d);
static void Main()
{
var d = new Data { V = 123 };
try { Console.WriteLine("result=" + Foo(d, null)); }
catch (NullReferenceException) { Console.WriteLine("NRE (correct)"); }
}
}Expected: NRE (correct) — callvirt on a null receiver must throw before the callee body runs.
Actual: result=123 — no exception; the null receiver check is dropped.
Checked corerun, -optimize+: prints result=123 with tiering on and with DOTNET_TieredCompilation=0; the same program compiled -optimize- prints NRE (correct).
Cause matches the report: the receiver is never fetched, so inlArgInfo[0].argTmpNum stays 0 (memset in impInlineInitVars), and impInlineIsThis (src\coreclr\jit\importer.cpp) then matches caller local V00 (d), making the field load of d.V look like a guaranteed this dereference, so fgInlinePrependStatements omits the null check.
Activity
dotnet-policy-service commentedon Sep 11, 2026
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.
MihuBot commentedon Sep 11, 2026
I'm a bot. Here is a possible related and/or duplicate issue (I may be wrong):
Fix JIT this pointer null check elision (#133737)
Fix JIT this pointer null check elision (dotnet#133737)
EgorBo commentedon Sep 18, 2026
Affected SDK versions: