Description

There is virtually no value in a debugger user stepping into a constructor for System.MulticastDelegate, especially since these constructors are typically inserted by the compiler and not explicitly called by user code. Currently, these constructors are [DebuggerNonUserCode], which allows them to be avoided when Just My Code is enabled. However, customers are now disabling Just My Code more often in order to debug the open source .NET Runtime sources. Stepping into System.MulticastDelegate can be a very annoying experience in this scenario. Marking these constructors as [DebuggerStepThrough] prevents them from being stepped into regardless of Just My Code setting. If there are .NET developers who still want to stop in these constructors, they can set breakpoints in the source code in order to stop.

Reproduction Steps

The following is a scenario that will currently cause a customer to step into System.MultiCastDelegate

Code:

    internal class Program
    {
        static void MyMethod(Action action)
        {
            action();
        }

        static void Main(string[] args)
        {
            MyMethod(() => { Console.WriteLine(); }); // bp here
        }
    }

In Visual Studio:

1. Disable Just My Code
2. Enable Supress JIT Optimization
3. Enable Microsoft Public Symbol Servers
4. F5 to hit the breakpoint
5. Ensure symbols have been loaded for System.Private.CoreLib
6. Step in

Expected behavior

I would expect the debugger to stop in MyMethod, as I am not interested in the infrastructure around instantiating the anonymous delegate.

Actual behavior

Source Link will obtain the source code for MulticastDelegate and stop in the constructor.

Regression?

N/A

Known Workarounds

Enable Just My Code, but that's not the point of this issue.

Configuration

No response

Other information

No response