Explicit delegate constructor not distinguished in C# decompilation.

[PetSerAl]

C# allows wrapping method group into delegate constructor. That disable delegate caching and construct new delegate instance on each invocation. That distinction visible in IL but lost in C# decompilation.

Input code

using System;

static class Test
{
	static Action Test1() => M;
	static Action Test2() => new(M);
	static void M() {}
}

Erroneous output

using System;

internal static class Test
{
	private static Action Test1()
	{
		return M;
	}

	private static Action Test2()
	{
		return M;
	}

	private static void M()
	{
	}
}

.class private auto ansi abstract sealed beforefieldinit Test
	extends [System.Runtime]System.Object
{
	// Nested Types
	.class nested private auto ansi abstract sealed beforefieldinit '<>O'
		extends [System.Runtime]System.Object
	{
		.custom instance void [System.Runtime]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor() = (
			01 00 00 00
		)
		// Fields
		.field public static class [System.Runtime]System.Action '<0>__M'

	} // end of class <>O


	// Methods
	.method private hidebysig static 
		class [System.Runtime]System.Action Test1 () cil managed 
	{
		// Method begins at RVA 0x2050
		// Header size: 1
		// Code size: 28 (0x1c)
		.maxstack 8

		// sequence point: (line 5, col 27) to (line 5, col 28) in M:\Temp\Test\Test.cs
		IL_0000: ldsfld class [System.Runtime]System.Action Test/'<>O'::'<0>__M'
		IL_0005: dup
		IL_0006: brtrue.s IL_001b

		IL_0008: pop
		IL_0009: ldnull
		IL_000a: ldftn void Test::M()
		IL_0010: newobj instance void [System.Runtime]System.Action::.ctor(object, native int)
		IL_0015: dup
		IL_0016: stsfld class [System.Runtime]System.Action Test/'<>O'::'<0>__M'

		IL_001b: ret
	} // end of method Test::Test1

	.method private hidebysig static 
		class [System.Runtime]System.Action Test2 () cil managed 
	{
		// Method begins at RVA 0x206d
		// Header size: 1
		// Code size: 13 (0xd)
		.maxstack 8

		// sequence point: (line 6, col 27) to (line 6, col 33) in M:\Temp\Test\Test.cs
		IL_0000: ldnull
		IL_0001: ldftn void Test::M()
		IL_0007: newobj instance void [System.Runtime]System.Action::.ctor(object, native int)
		IL_000c: ret
	} // end of method Test::Test2

	.method private hidebysig static 
		void M () cil managed 
	{
		// Method begins at RVA 0x207b
		// Header size: 1
		// Code size: 2 (0x2)
		.maxstack 8

		// sequence point: (line 7, col 18) to (line 7, col 19) in M:\Temp\Test\Test.cs
		IL_0000: nop
		// sequence point: (line 7, col 19) to (line 7, col 20) in M:\Temp\Test\Test.cs
		IL_0001: ret
	} // end of method Test::M

} // end of class Test

Details

• Product in use: ILSpy
• ILSpy version: 10.1.1.8388+1377eb6e7351b21112858c8c1df39848f40181ec
• .NET version: 10.0.10-servicing.26326.116+f7d90799ce4ef09a0bb257852a57248d2a8fb8dd

[siegfriedpammer]

Investigation results (analysis written by an AI agent, posted on my behalf):

Confirmed. Since C# 11, Roslyn caches method-group-to-delegate conversions with a static, receiver-less target in compiler-generated <>O container classes, while an explicit delegate creation (new Action(M)) suppresses the cache. This happens in both Debug and Release builds (it is lowering, not an optimization pass), the difference is observable via ReferenceEquals(Test1(), Test1()), and ILSpy currently renders both forms as M, so recompiling the decompiled output silently changes the semantics of the explicit form.

Which compilers are affected

Verified empirically by compiling the two methods from the report and inspecting the IL:

Compiler	LangVersion	=> M	=> new Action(M)
Roslyn 2.10.0	7.3	plain newobj	plain newobj (identical IL)
Roslyn 3.11.0	9	plain newobj	plain newobj (identical IL)
Roslyn 4.14.0	10	plain newobj	plain newobj (identical IL)
Roslyn 4.14.0	11	<>O.<0>__M cache	plain newobj
Roslyn 5.9 (.NET 11 SDK)	latest	<>O.<0>__M cache	plain newobj

Two consequences:

• The gate is LangVersion >= 11, not the compiler binary: a modern compiler run with <LangVersion>10</LangVersion> emits no caches, and both forms compile to byte-identical IL. So for decompilation settings below C# 11 the current output is already lossless and nothing needs to change there.
• LangVersion is not recorded in assembly metadata (and RefSafetyRulesAttribute is only emitted when ref features are used - verified absent from this issue's own sample), so there is no reliable way to detect from a module whether it was compiled with caching semantics.

Where the distinction is lost in the decompiler

Two coordinated places:

1. CachedDelegateInitialization (IL transform) collapses the <>O.<0>__M null-check/stsfld shape into a bare NewObj - after that, cached and uncached constructions are structurally identical ILAst.
2. CallBuilder.HandleDelegateConstruction actually always builds new DelegateType(M); the bare-M form comes from TranslatedExpression.ConvertTo unwrapping it under DecompilerSettings.UseImplicitMethodGroupConversion (the WinForms InitializeComponent path already disables that unwrap wholesale).

Possible fix

Carry a "came from a cache" flag on the NewObj (set at the CachedDelegateInitialization collapse sites), add a C#11-gated setting, and in CallBuilder keep the explicit new DelegateType(M) when the construction is uncached but cache-eligible (static target method, ldnull this-arg - the eligibility predicate needs to mirror Roslyn's DelegateCacheContainer lowering). Cached constructions and cache-ineligible ones (instance methods, bound receivers, ldvirtftn) keep the bare method group, which is already correct.

The open design question: since compile-time LangVersion is undetectable, gating purely on the decompiler's language-version setting means assemblies compiled with LangVersion < 11 but decompiled with default (latest) settings would render every static method group - e.g. list.Select(Parse) - as new Func<string, int>(Parse), because none of them are cached. That is faithful for round-tripping under C# 11+, but a noticeable cosmetic regression for reading older assemblies unless the user selects the matching language version. A module-level heuristic (e.g. "does the module contain any <>O container") would avoid the churn but is unsound: a C# 11 module whose delegate creations are all explicit contains no container at all - exactly the case this issue is about.