Skipped argument evaluation for calls replaced by interceptors

[ufcpp]

Summary

I'd like to propose a language feature that enables removal of argument-evaluation dead code when a call is replaced by Interceptors.
Today, Interceptors can replace the call target, but argument construction/evaluation may still remain in IL even when completely unused, causing code bloat (Dead code remains in the compiled output).

Motivation

In some source-generator scenarios, the result can be computed at compile time (e.g., compile-time string conversion/formatting), making the original arguments entirely unnecessary.
However, the original argument expression may still be emitted/evaluated, unlike ConditionalAttribute where omitted calls also omit argument evaluation.

As a concrete example:

For interpolated strings specifically, the culture-dependent formatting issue and why constant interpolated strings are hard has been discussed in csharplang:
#2951 (comment)

I tried to solve this issue using Interceptors:
https://github.com/ufcpp/SourceGeneratorDemo/blob/main/ConstantInterpolation/

This proposal focuses on providing a mechanism to remove the remaining dead argument-evaluation code in that kind of solution.

Proposal

Introduce a parameter attribute, e.g. [Unused], that is similar to Caller Info attributes but has the opposite effect: it replaces actual arguments with default values.

• Target: parameters on the generated interceptor method that the generator author explicitly declares as unused.
• This is a static declaration by the generator author that those parameter values are not needed by the interceptor body.
• Arguments mapped to [Unused] parameters are expected not to be evaluated/emitted at the call site.
• Like ConditionalAttribute, any side effects in the omitted argument expressions are also eliminated.

Example (conceptual)

For example, suppose we have a method like the following.

public static class ConstantInterpolationExtensions
{
    public static string Local(
        this string s,
        string cultureName = "")
        => RuntimeFallback(s, cultureName);
}

var s = $"ab{1}cd{1.2}ef{1.1m}".Local("fr");
// intercepted => precomputed constant string for "fr"
// (a representative locale that uses a comma as the decimal separator)

For this, the generator produces an interceptor method like the following.

namespace Interceptors.Generated
{
    internal static class ConstantInterpolation
    {
        [System.Runtime.CompilerServices.InterceptsLocation(1, "...")]
        internal static string Local_Intercepted(
            [Unused] this string s = null!,
            [Unused] string cultureName = null!)
            => "ab1cd1,2ef1,1";
    }
}

Without the [Unused] mechanism, code at the call site would still be compiled into code like the following.

DefaultInterpolatedStringHandler h = new(6, 3);
h.AppendLiteral("ab");
h.AppendFormatted(1);
h.AppendLiteral("cd");
h.AppendFormatted(1.2);
h.AppendLiteral("ef");
h.AppendFormatted(1.1m);
var s = Interceptors.Generated.ConstantInterpolation.Local_Intercepted(h.ToStringAndClear(), "fr");

With this proposal, due to the [Unused] effect on the generated interceptor parameters,
evaluation/emission of the corresponding original arguments is omitted:

var s = Interceptors.Generated.ConstantInterpolation.Local_Intercepted(null, null);

Why this shape

• Fits existing C# design patterns (Caller Info on optional parameters).
• Explicit opt-in by generator author.
• Does not require new call site syntax.

Design constraints / questions

• Should the feature apply to interceptor scenarios only, or be available more broadly?

Expected benefit

• Removes dead IL/code bloat in interceptor and similar scenarios.
• Better parity with developer expectations from ConditionalAttribute call omission behavior.
• Makes compile-time optimization scenarios cleaner and more predictable.