csharp-ls Language Server

The language server automatically suppresses inlay hints in the following syntactically redundant scenarios:

1. 'as' Casts If the target type of an as expression is already present in the statement, the hint is suppressed.

// No hint for 'other' because 'DBBankAccount' is already present
var other = obj as DBBankAccount;

2. String Literals and Interpolated Strings Plain string literals and interpolated strings have their types implied by their syntax, so hints are suppressed.

// No hint for 'uniqueAccountKey' (type: string)
var uniqueAccountKey = "account_number_unique";

// No hint for 'logMessage' (type: string?)
var logMessage = $"{level}: {message}";

public override bool Equals(object obj)
{
    var other = obj as DBBankAccount;
    return other != null && this.Id == other.Id;
}

var uniqueAccountKey = "account_number_unique";
var logMessage = $"{level}: {message}";

In C#, calls to formatting methods (like string.Format, Logger.DebugFormat, Logger.InfoFormat, or Logger.ErrorFormat) often include a format string with {n} placeholders. When these methods are called, the language server may provide inlay hints like format:, arg0:, arg1:, etc.

Because the format string itself already explicitly defines the positional correspondence via the {n} placeholders, these parameter name hints are often redundant and add zero information.

Suppression Rule Candidate: Suppress parameter-name hints for arguments following a composite/format string parameter on well-known formatting methods or any method where the preceding string-literal argument contains {n}-style placeholders.

// Redundant hints: format:, arg0:, arg1:
Logger.DebugFormat(
    "{0}: cannot do the thing; reason",
    nameof(SomeMethodAsync));

// Redundant hints: format:, arg0:, arg1:, arg2:
throw new ResourceOpException(
    string.Format(
        "{0}: mode could not be set to `{1}`: {2}",
        nameof(this.SetModeAsync), mode, modeChangeCondition));

The csharp-language-server implements several heuristic rules to reduce 'superfluous' or redundant inlay hints (both parameter names and variable types) to improve code readability. These rules are primarily implemented within the toInlayHint function in Handlers/InlayHint.fs and affect the textDocument/inlayHint LSP capability.

Parameter Name Suppression Rules

• Same-name suppression: Hints are suppressed if the argument expression's identifier matches the parameter name (e.g., this.Foo vs parameter foo).
• Uninformative names: Hints are suppressed for short names (length $\le 2$) or numbered suffixes (e.g., arg0, val1, path2).
• Generic 'obj' names: Explicitly suppresses hints for common generic parameter names like obj.
• Single lambda-argument calls: For methods with exactly one effective argument, the parameter hint is suppressed if that argument is a lambda expression (e.g., Where(x => ...)). Note that trailing CancellationToken arguments are ignored when calculating the 'effective' argument count.
• Sole 'value' parameter: Suppresses the value: hint for methods where the parameter name is value and it is the only effective argument (e.g., Contains(value)).

Variable Type Suppression Rules

Type hints (e.g., : string) are suppressed when the type is already explicitly visible in the initializer:

• Generic invocations: When the type is in the explicit type-argument list (e.g., Enum.Parse<DayOfWeek>(...)).
• Object creation: When using new Type(...) or new Type { ... } (excludes target-typed new()).
• Static invocation qualifiers: When the type is the qualifier of a static method (e.g., string.Format(...)).
• 'as' casts: When the target type of an as expression matches the inferred type (e.g., obj as Widget).
• Literals: For numeric, string, character, boolean, and interpolated string literals.
• Fluent chains: When the element type was already spelled out earlier in the same fluent invocation chain (e.g., db.Query<DBSalesOrder>()...ToListAsync()).

In this project's transport layer, using Async.RunSynchronously(timeout=N) does not provide a hard wall-clock guarantee for stopping a hung JSON-RPC call.

This is because the transport uses a MailboxProcessor created without a CancellationToken. Consequently, PostAndAsyncReply takes a 'fast path' (AwaitResult_NoDirectCancelOrTimeout) that does not register a callback on the ambient cancellation token. When the RunSynchronously timer fires, it signals cancellation, but the underlying async workflow is uncooperative and never wakes up, causing the thread to hang indefinitely.

Key distinction:

• Async.RunSynchronously(timeout): Uses cooperative cancellation. It requests cancellation and trusts the code to notice. If the code is uncooperative (like the current transport fast path), it hangs.
• Task.Wait(timeout): Uses an OS-level wait handle. It releases the calling thread after N ms regardless of the task's state, though the underlying async work may continue to run in the background.

To prevent state leaks and ensure reliable timeouts, the JSON-RPC transport manages deadlines internally within the actor rather than relying on the built-in PostAndAsyncReply timeout parameter.

The mechanism works as follows:

1. Embedding Deadlines: A sendJsonRpcCallWithTimeout function accepts an optional TimeSpan. This timeout is embedded into the SendCall event.
2. Recording Deadlines: When the actor processes a SendCall, it calculates an absolute deadline (DateTimeOffset.UtcNow + timeout) and stores it in a PendingCall entry within PendingOutboundCalls.
3. Global Timer: The actor owns a single System.Threading.Timer. This timer is armed to fire at the earliest deadline among all pending calls.
4. Timeout Processing: When the timer fires, it posts a CheckTimeouts event to the actor. The actor sweeps PendingOutboundCalls, identifies expired entries, replies to them with a timeout error (code -32000), and removes them from the map.
5. Rescheduling: After sweeping, the actor re-arms the single timer for the next earliest remaining deadline using timer.Change.

The C# language server implements a series of isTypeSpelledOutIn* validation filters to suppress redundant inlay hints. These filters identify cases where the type information provided by a hint is already explicitly present in the code's syntax, making the hint superfluous.

Redundancy is detected in several patterns:

• Generic Invocations: When the type argument is already present in the method call (e.g., Query<T>()).
• Object Creation: When the type is part of the constructor call.
• Static Invocations: When the type is part of the static qualifier.
• As-casts: When the target type of an as expression is already spelled out on the same line.
• Literals and Interpolated Strings: When the type is directly implied by the syntax (e.g., a string literal or an interpolated string).
• Invocation Chains: When the element type of a materialized result (like .ToListAsync()) was already explicitly defined earlier in the same fluent chain (e.g., in a Query<T>() call).