• Add interpolated string handler support for deferred log message construction
• Implement level-specific handlers (Trace, Debug, Info, Warn, Error) to avoid allocations
• Add compatibility shims for .NET versions prior to 8.0
• Guard string construction with IsEnabled checks in Logger implementation

Add interpolated string handler method overloads

• Added System.Runtime.CompilerServices using directive
• Added new overloads for each log level method accepting interpolated string handlers
• Each handler method uses [InterpolatedStringHandlerArgument("")] attribute
• Handlers defer string construction until log level is confirmed enabled

dotnet/src/webdriver/Internal/Logging/ILogger.cs

Implement interpolated string handler types for all log levels

• Created five level-specific handler structs: TraceLogStringHandler, DebugLogStringHandler,
 InfoLogStringHandler, WarnLogStringHandler, ErrorLogStringHandler
• Implemented core LogInterpolatedStringHandler with StringBuilder-based deferred string
 construction
• Each handler wraps the core handler and delegates AppendLiteral and AppendFormatted methods
• Handlers only allocate StringBuilder when log level is enabled

dotnet/src/webdriver/Internal/Logging/LogInterpolatedStringHandler.cs

Add handler-based log methods with IsEnabled guards

• Added IsEnabled checks to existing string-based log methods (Trace, Debug, Info, Warn, Error)
• Implemented new handler-based overloads for each log level
• Handler methods extract formatted string via ToStringAndClear() and log if enabled
• Prevents unnecessary LogMessage calls when log level is disabled

dotnet/src/webdriver/Internal/Logging/Logger.cs

Description

New overloads were added to the public ILogger interface, which is a source-breaking change for
any external implementers of ILogger. This violates the API compatibility requirement unless a
compatibility strategy (e.g., new interface + adapter, default interface methods, or deprecation
plan) is provided.

Code

dotnet/src/webdriver/Internal/Logging/ILogger.cs[R35-52]

+    /// <summary>
+    /// Writes a trace-level log message using an interpolated string handler that defers string construction.
+    /// </summary>
+    /// <param name="handler">The interpolated string handler.</param>
+    void Trace([InterpolatedStringHandlerArgument("")] ref TraceLogStringHandler handler);
+
    /// <summary>
    /// Writes a debug-level log message.
    /// </summary>
    /// <param name="message">The log message.</param>
    void Debug(string message);

+    /// <summary>
+    /// Writes a debug-level log message using an interpolated string handler that defers string construction.
+    /// </summary>
+    /// <param name="handler">The interpolated string handler.</param>
+    void Debug([InterpolatedStringHandlerArgument("")] ref DebugLogStringHandler handler);
+

Evidence

PR Compliance ID 5 requires preserving public API/ABI compatibility. ILogger is declared as
public interface ILogger, and this PR adds new members like `Trace(ref TraceLogStringHandler
handler) and Debug(ref DebugLogStringHandler handler)`, which will break compilation for any code
that implements ILogger but is not updated in lockstep.

AGENTS.md
dotnet/src/webdriver/Internal/Logging/ILogger.cs[27-52]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`ILogger` is a `public interface`, and adding new members is a breaking change for any downstream implementers.

## Issue Context
This PR adds interpolated string handler overloads directly onto `ILogger`.

## Fix Focus Areas
- dotnet/src/webdriver/Internal/Logging/ILogger.cs[27-88]
- dotnet/src/webdriver/Internal/Logging/Logger.cs[38-101]

## Suggested directions (pick one)
- Introduce a new interface (e.g., `IInterpolatedStringLogger`) for the handler overloads and keep `ILogger` unchanged; update internal usage to use the new interface when available.
- If language/runtime support allows, use default interface implementations for the new methods to preserve binary/source compatibility.
- If `ILogger` is not intended to be public API, consider making it `internal` (only if it does not affect public surface area) and/or providing a public, stable abstraction.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The new handler-based ILogger overloads are not meaningfully implementable by external ILogger
implementations because the handlers’ rendered message is only available via `internal
ToStringAndClear()`. Downstream implementations are forced to add these methods (due to the
interface change) but cannot access the formatted message to log it.

Code

dotnet/src/webdriver/Internal/Logging/LogInterpolatedStringHandler.cs[R55-62]

+    /// <inheritdoc cref="LogInterpolatedStringHandler.AppendFormatted{T}(T, int)"/>
+    public void AppendFormatted<T>(T value, int alignment) => _inner.AppendFormatted(value, alignment);
+
+    /// <inheritdoc cref="LogInterpolatedStringHandler.AppendFormatted{T}(T, int, string?)"/>
+    public void AppendFormatted<T>(T value, int alignment, string? format) => _inner.AppendFormatted(value, alignment, format);
+
+    internal string ToStringAndClear() => _inner.ToStringAndClear();
+}

Evidence

The handler types are public and are required by the public ILogger interface, but the only way to
obtain the formatted string (ToStringAndClear) is internal, which is inaccessible to consumers
in other assemblies. This makes it impossible for external implementations of ILogger to correctly
implement the new overloads.

dotnet/src/webdriver/Internal/Logging/ILogger.cs[27-88]
dotnet/src/webdriver/Internal/Logging/LogInterpolatedStringHandler.cs[25-62]
dotnet/src/webdriver/Internal/Logging/LogInterpolatedStringHandler.cs[220-304]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`ILogger` now requires overloads taking `ref TraceLogStringHandler` (etc.), but the handler types do not publicly expose the rendered message, preventing external `ILogger` implementations from logging the constructed message.

### Issue Context
`ToStringAndClear()` is currently `internal` on both the wrapper handlers and the core handler.

### How to fix
Choose one (consistent with intended API surface):
- If handler overloads remain part of a **public** contract, make a **public** method to retrieve the rendered content (e.g., `public string ToStringAndClear()` or `public override string ToString()`), and consider also exposing an `IsEnabled`/`HasValue` flag so implementations can no-op safely.
- If these overloads are intended to be internal-only, remove them from the public `ILogger` contract (see also the interface-breaking-change finding).

### Fix Focus Areas
- dotnet/src/webdriver/Internal/Logging/ILogger.cs[35-88]
- dotnet/src/webdriver/Internal/Logging/LogInterpolatedStringHandler.cs[25-62]
- dotnet/src/webdriver/Internal/Logging/LogInterpolatedStringHandler.cs[220-304]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

This PR introduces new interpolated string handler types and new ILogger overloads, but no
corresponding tests are added/updated to validate formatting correctness and the enabled/disabled
behavior. Lack of coverage increases regression risk for this new logging API surface.

Code

dotnet/src/webdriver/Internal/Logging/LogInterpolatedStringHandler.cs[R25-62]

+/// <summary>
+/// Interpolated string handler for <see cref="LogEventLevel.Trace"/> log messages.
+/// Defers string construction until the log level is confirmed enabled.
+/// </summary>
+[InterpolatedStringHandler]
+public ref struct TraceLogStringHandler
+{
+    private LogInterpolatedStringHandler _inner;
+
+    /// <summary>
+    /// Initializes a new instance of the <see cref="TraceLogStringHandler"/> struct.
+    /// </summary>
+    /// <param name="literalLength">The number of literal characters in the interpolated string.</param>
+    /// <param name="formattedCount">The number of interpolation holes in the interpolated string.</param>
+    /// <param name="logger">The logger to check for enabled status.</param>
+    /// <param name="isEnabled">When this method returns, indicates whether the handler is enabled.</param>
+    public TraceLogStringHandler(int literalLength, int formattedCount, ILogger logger, out bool isEnabled)
+    {
+        _inner = new LogInterpolatedStringHandler(literalLength, formattedCount, logger, LogEventLevel.Trace, out isEnabled);
+    }
+
+    /// <inheritdoc cref="LogInterpolatedStringHandler.AppendLiteral(string)"/>
+    public void AppendLiteral(string s) => _inner.AppendLiteral(s);
+
+    /// <inheritdoc cref="LogInterpolatedStringHandler.AppendFormatted{T}(T)"/>
+    public void AppendFormatted<T>(T value) => _inner.AppendFormatted(value);
+
+    /// <inheritdoc cref="LogInterpolatedStringHandler.AppendFormatted{T}(T, string?)"/>
+    public void AppendFormatted<T>(T value, string? format) => _inner.AppendFormatted(value, format);
+
+    /// <inheritdoc cref="LogInterpolatedStringHandler.AppendFormatted{T}(T, int)"/>
+    public void AppendFormatted<T>(T value, int alignment) => _inner.AppendFormatted(value, alignment);
+
+    /// <inheritdoc cref="LogInterpolatedStringHandler.AppendFormatted{T}(T, int, string?)"/>
+    public void AppendFormatted<T>(T value, int alignment, string? format) => _inner.AppendFormatted(value, alignment, format);
+
+    internal string ToStringAndClear() => _inner.ToStringAndClear();
+}

Evidence

PR Compliance ID 6 requires functional changes/additions to include tests. The PR adds new
handler-based logging APIs (TraceLogStringHandler etc.) and relies on compiler-enabled IsEnabled
guarding, but the PR diff contains only production logging changes and does not include test updates
for these new code paths.

AGENTS.md
dotnet/src/webdriver/Internal/Logging/LogInterpolatedStringHandler.cs[25-245]
dotnet/src/webdriver/Internal/Logging/ILogger.cs[35-88]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
New interpolated string handler overloads and handler types were added without tests covering the new API paths.

## Issue Context
The feature depends on the interpolated string handler pattern correctly deferring construction when `IsEnabled` is false, and formatting correctly when enabled.

## Fix Focus Areas
- dotnet/src/webdriver/Internal/Logging/LogInterpolatedStringHandler.cs[25-304]
- dotnet/src/webdriver/Internal/Logging/Logger.cs[38-101]
- dotnet/src/webdriver/Internal/Logging/ILogger.cs[35-88]

## Test expectations
- Add unit tests that call the new overloads via interpolated strings (e.g., `logger.Info($"value={expensive()}" )`) and assert `expensive()` is not evaluated when level is disabled.
- Add unit tests asserting formatted output matches expected strings when enabled (including `alignment` and `format` variants).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

When logs are enabled, the handler’s formatted/aligned append paths allocate a new composite format
string per interpolation hole (via $"{...}") and then route through StringBuilder.AppendFormat,
adding avoidable allocations/CPU in enabled logging scenarios. This can partially offset the
performance benefit for heavily-used logs with alignment/format specifiers.

Code

dotnet/src/webdriver/Internal/Logging/LogInterpolatedStringHandler.cs[R272-298]

+    public void AppendFormatted<T>(T value, string? format)
+    {
+        _builder?.AppendFormat($"{{0:{format}}}", value);
+    }
+
+    /// <summary>
+    /// Appends a formatted value with alignment to the handler.
+    /// </summary>
+    /// <typeparam name="T">The type of the value to format.</typeparam>
+    /// <param name="value">The value to format and append.</param>
+    /// <param name="alignment">The alignment for the formatted value.</param>
+    public void AppendFormatted<T>(T value, int alignment)
+    {
+        _builder?.AppendFormat($"{{0,{alignment}}}", value);
+    }
+
+    /// <summary>
+    /// Appends a formatted value with alignment and a format string to the handler.
+    /// </summary>
+    /// <typeparam name="T">The type of the value to format.</typeparam>
+    /// <param name="value">The value to format and append.</param>
+    /// <param name="alignment">The alignment for the formatted value.</param>
+    /// <param name="format">The format string.</param>
+    public void AppendFormatted<T>(T value, int alignment, string? format)
+    {
+        _builder?.AppendFormat($"{{0,{alignment}:{format}}}", value);
+    }

Evidence

The handler constructs a new string for the composite format pattern on every AppendFormatted call
with a format and/or alignment and then uses AppendFormat, which implies repeated
parsing/formatting work in the enabled path.

dotnet/src/webdriver/Internal/Logging/LogInterpolatedStringHandler.cs[266-298]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`AppendFormatted` overloads build composite format strings (e.g., `$"{{0:{format}}}"`) per hole and call `StringBuilder.AppendFormat`, introducing extra allocations and format parsing.

### Issue Context
This affects the enabled-logging path for interpolations that use alignment and/or a format string.

### How to fix
Implement formatting without building composite format strings:
- Use `IFormattable` / `ISpanFormattable` to format directly into the builder (or temporary stack buffer) and apply alignment via padding.
- On `net8.0`, consider conditionally using `DefaultInterpolatedStringHandler` or `StringBuilder.AppendInterpolatedStringHandler` to avoid per-hole composite-format-string creation.

### Fix Focus Areas
- dotnet/src/webdriver/Internal/Logging/LogInterpolatedStringHandler.cs[266-298]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools