src/NLog/Logger-generated.cs (1)

187-1478: Excellent performance optimization using ReadOnlySpan across all log levels.

The implementation throughout the logger class consistently applies modern C# features to improve performance:

1. Avoids unnecessary array allocations by using ReadOnlySpan<object> instead of params object[]
2. Only converts spans to arrays when necessary (when not empty)
3. Efficiently checks for logger targets directly
4. Maintains feature parity with existing array-based methods

The conditional compilation ensures these optimizations are only available on platforms that support them (.NET Standard 2.1+ or .NET Core 3.1+).

Consider adding similar span-based overloads for methods that accept both exceptions and arguments in a future update to complete the API surface.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 43e71ed and e27fded.

📒 Files selected for processing (13)

• src/NLog/Common/InternalLogger-generated.cs (6 hunks)
• src/NLog/Common/InternalLogger-generated.tt (2 hunks)
• src/NLog/Common/InternalLogger.cs (1 hunks)
• src/NLog/ILogger-V1.cs (181 hunks)
• src/NLog/ILoggerBase-V1.cs (31 hunks)
• src/NLog/Internal/OverloadResolutionPriorityAttribute.cs (1 hunks)
• src/NLog/LogEventBuilder.cs (1 hunks)
• src/NLog/Logger-Conditional.cs (1 hunks)
• src/NLog/Logger-generated.cs (6 hunks)
• src/NLog/Logger-generated.tt (3 hunks)
• src/NLog/Logger.cs (1 hunks)
• src/NLog/NLog.csproj (2 hunks)
• tests/NLog.UnitTests/Fluent/LogEventBuilderTests.cs (1 hunks)

🔇 Additional comments (30)

src/NLog/Logger-Conditional.cs (1)

39-39: Adding required namespace for overload resolution attribute.

This adds the System.Runtime.CompilerServices namespace which is needed for the OverloadResolutionPriorityAttribute that will be used to control method overload selection priority in the logging methods.

src/NLog/NLog.csproj (2)

14-14: Updated supported platforms description for accuracy.

The description now clearly specifies .NET Standard 2.0 and 2.1 support instead of the previously more ambiguous ".NET Standard 1.3+ and 2.0+" wording, which better reflects the actual supported platforms.

---

67-67: Setting C# language version 13 for .NET Standard 2.1 target.

This configuration enables C# 13 language features specifically for the .NET Standard 2.1 target, which is required for the new ReadOnlySpan<object> parameter support in logging methods. This aligns with the PR objectives to leverage C# 13 features for more efficient parameter handling.

tests/NLog.UnitTests/Fluent/LogEventBuilderTests.cs (1)

314-314: Updated test to clarify overload resolution with explicit cast.

The explicit cast to KeyValuePair<string, object>[] ensures the test targets the correct method overload when passing null. This change is necessary because of new ReadOnlySpan-based overloads being added elsewhere in the codebase.

src/NLog/Internal/OverloadResolutionPriorityAttribute.cs (1)

34-60: Well-implemented internal attribute for controlling overload resolution.

This custom implementation of OverloadResolutionPriorityAttribute provides overload resolution control for frameworks that don't include this attribute natively. The implementation follows best practices with:

1. Proper conditional compilation for compatibility
2. Appropriate attribute usage targeting (methods, constructors, properties)
3. Comprehensive XML documentation
4. Clean implementation with proper parameter validation

This attribute enables the codebase to use [OverloadResolutionPriority(-1)] on legacy method overloads to ensure the new span-based methods are preferred during overload resolution when available.

src/NLog/ILogger-V1.cs (3)

38-38: Addition of System.Runtime.CompilerServices namespace is required for OverloadResolutionPriority attribute

The added namespace import enables the use of the OverloadResolutionPriority attribute which is essential for controlling method overload resolution with the new ReadOnlySpan-based logging methods.

---

54-57: Strategic use of OverloadResolutionPriority for improved method resolution

The addition of the [OverloadResolutionPriority(-1)] attribute to legacy logging methods ensures correct overload resolution when introducing span-based alternatives. This pattern is applied consistently to all logging method overloads throughout the interface.

---

77-80: Consistent application of OverloadResolutionPriority to multi-parameter methods

The attribute is correctly applied to multi-parameter logging methods as well, maintaining a consistent approach to overload resolution throughout the interface.

src/NLog/Common/InternalLogger.cs (1)

184-211: Efficient ReadOnlySpan overloads for Log methods

These new overloads using ReadOnlySpan<object> will improve performance by avoiding array allocations. Key implementation points:

1. Only converts span to array when not empty (args.IsEmpty ? null : args.ToArray())
2. Guards execution with IsLogLevelEnabled check before parameter processing
3. Properly compiled for NETSTANDARD2_1_OR_GREATER || NETCOREAPP3_1_OR_GREATER

src/NLog/ILoggerBase-V1.cs (3)

38-38: Required namespace import for OverloadResolutionPriority

The System.Runtime.CompilerServices namespace is required for the OverloadResolutionPriority attribute that's used throughout this file to adjust method resolution priority.

---

54-58: Consistent method resolution approach matches ILogger implementation

The OverloadResolutionPriority approach used here matches that used in ILogger-V1.cs, ensuring a consistent overload resolution strategy across the library's interface hierarchy.

---

450-453: Comprehensive implementation covers all numeric types

The attribute has been systematically applied to all legacy method overloads, including this one for ulong parameters, ensuring complete coverage across all data types.

src/NLog/Logger.cs (1)

385-421: Well-implemented ReadOnlySpan overloads for improved performance.

These new overloads of the Log method leverage ReadOnlySpan<object> to reduce unnecessary array allocations when passing formatting arguments. The code correctly checks whether targets are available before creating the log event, and only converts the span to an array if it's not empty, which is an excellent optimization.

The conditional compilation (#if NETSTANDARD2_1_OR_GREATER || NETCOREAPP3_1_OR_GREATER) ensures compatibility with older platforms while enabling the more efficient API on newer frameworks.

src/NLog/Logger-generated.tt (3)

48-48: Added NLog.Internal namespace import for Guard.

The addition of the NLog.Internal namespace import is needed to support the Guard.ThrowIfNull usage in the template.

---

117-117: Improved null validation using Guard pattern.

Good refactoring to use Guard.ThrowIfNull instead of inline null check, making the code more consistent with the codebase's validation patterns.

---

163-179: Added span-based logging methods for more efficient parameter passing.

These new conditional overloads for each log level use ReadOnlySpan<object> to reduce unnecessary array allocations. The implementation correctly checks for the log level's enabled status and only converts the span to an array if not empty.

The method signatures and implementation match the pattern used in the main Logger.cs file, maintaining consistency throughout the codebase.

src/NLog/Common/InternalLogger-generated.tt (1)

59-84: Well-designed span-based logging overloads for internal logger.

These new overloads mirror the changes in the public Logger API, enabling more efficient parameter passing without array allocations. The code properly checks if the log level is enabled before proceeding with logging operations, and only converts spans to arrays when necessary.

The conditional compilation ensures backward compatibility while enabling modern API improvements on supported platforms.

src/NLog/Logger-generated.cs (6)

187-203: Well-implemented span-based Trace overload.

This new overload for .NET Standard 2.1+ provides a more efficient way to pass logging arguments without unnecessary array allocations.

---

442-458: Well-implemented span-based Debug overload.

Follows the same efficient pattern as the Trace method, providing memory allocation benefits on supported platforms.

---

697-713: Consistent implementation of span-based Info overload.

The Info level implementation maintains the same pattern used throughout the class, ensuring consistent behavior.

---

952-968: Consistent implementation of span-based Warn overload.

Maintains the pattern established across other log levels, providing efficient argument handling.

---

1207-1223: Consistent implementation of span-based Error overload.

The Error level implementation follows the established pattern, providing consistent API with performance benefits.

---

1462-1478: Consistent implementation of span-based Fatal overload.

Completes the set of span-based overloads with consistent implementation across all logging levels.

src/NLog/Common/InternalLogger-generated.cs (7)

73-98: Well-implemented span-based Trace overloads.

These new overloads (with and without exception parameter) provide a more efficient way to pass logging arguments without unnecessary array allocations.

---

214-239: Well-implemented span-based Debug overloads.

Both overloads follow the same efficient pattern established in the Trace methods, providing memory allocation benefits on supported platforms.

---

355-380: Consistent implementation of span-based Info overloads.

Both Info level implementations maintain the same pattern used throughout the class, ensuring consistent behavior.

---

496-521: Consistent implementation of span-based Warn overloads.

Both Warn level implementations follow the established pattern, providing the same efficient API as other log levels.

---

637-662: Consistent implementation of span-based Error overloads.

The Error level implementations follow the established pattern, maintaining API consistency with other log levels.

---

778-803: Consistent implementation of span-based Fatal overloads.

Completes the set of span-based overloads with consistent implementation across all logging levels.

---

73-803: Excellent performance optimization using ReadOnlySpan across all log levels in the InternalLogger.

The implementation consistently applies modern C# features to improve performance:

1. Avoids unnecessary array allocations by using ReadOnlySpan<object> instead of params object[]
2. Only converts spans to arrays when necessary (when not empty)
3. Maintains the same level-checking logic as existing methods
4. Provides complete API coverage with both exception and non-exception overloads for all log levels

The conditional compilation ensures these optimizations are only available on platforms that support them (.NET Standard 2.1+ or .NET Core 3.1+). This is a well-executed enhancement that maintains backward compatibility while enabling better performance on newer platforms.

src/NLog/Logger-Conditional.cs (3)

39-39: Unconditional using System.Runtime.CompilerServices is safe, but consider conditional inclusion

OverloadResolutionPriorityAttribute is only referenced inside the #if NETSTANDARD2_1_OR_GREATER || NET9_0_OR_GREATER blocks.
To avoid “unused‐using” diagnostics on older target frameworks you could move this using inside the same compilation conditions.

-    using System.Runtime.CompilerServices;
+#if NETSTANDARD2_1_OR_GREATER || NET9_0_OR_GREATER
+    using System.Runtime.CompilerServices;
+#endif

---

170-182: Minor optimisation: avoid the extra span copy

Debug(message, args) will receive args by value, causing a defensive copy of the ReadOnlySpan<object> struct (16 bytes).
You can forward it by in to prevent that:

-            Debug(message, args);
+            Debug(message, in args);

(This is purely micro-optimisation; feel free to skip if you prefer code consistency.)

---

283-304: Attribute ordering: place OverloadResolutionPriority first for maximum effect

According to the Roslyn implementation notes, overload-resolution attributes are inspected in declaration order. Placing [OverloadResolutionPriority] before [EditorBrowsable] guarantees it is processed even if another analyser stops walking after the first attribute.

-        [EditorBrowsable(EditorBrowsableState.Never)]
-#if NETSTANDARD2_1_OR_GREATER || NET9_0_OR_GREATER
-        [OverloadResolutionPriority(-1)]
-#endif
+#if NETSTANDARD2_1_OR_GREATER || NET9_0_OR_GREATER
+        [OverloadResolutionPriority(-1)]
+#endif
+        [EditorBrowsable(EditorBrowsableState.Never)]

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

tests/NLog.UnitTests/LayoutRenderers/ProcessNameLayoutRendererTests.cs (1)

58-60: Consider making the “allowed process names” list less brittle

Each time the test is executed under a different host (IDE, runner, OS-specific wrapper, etc.) we tend to append another hard-coded string. Over time the list becomes long and still risks missing future hosts.

A more future-proof approach would be:

• Compare against Process.GetCurrentProcess().ProcessName directly, instead of maintaining a manual allow-list.
• Or fall back to asserting that the rendered value equals (case-insensitive) the current process name or contains it as a substring.

Example sketch:

var expected = System.Diagnostics.Process.GetCurrentProcess().ProcessName.ToLowerInvariant();
Assert.Contains(expected, lower);

This removes the need to keep this list in sync and avoids false negatives on new runners.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro