Reviewing files that changed from the base of the PR and between f06b012 and 6cc0dc3.

• src/NLog/Common/AsyncLogEventInfo.cs
• src/NLog/Common/InternalLogger.cs
• src/NLog/Conditions/ConditionExpression.cs
• src/NLog/Conditions/ConditionLiteralExpression.cs
• src/NLog/Conditions/ConditionMethods.cs
• src/NLog/Conditions/ConditionRelationalExpression.cs
• src/NLog/Config/AssemblyExtensionLoader.cs
• src/NLog/Config/LoggerNameMatcher.cs
• src/NLog/Config/LoggingConfiguration.cs
• src/NLog/Config/MethodFactory.cs
• src/NLog/Config/PropertyTypeConverter.cs
• src/NLog/Filters/WhenRepeatedFilter.cs
• src/NLog/Internal/AppEnvironmentWrapper.cs
• src/NLog/Internal/AssemblyHelpers.cs
• src/NLog/Internal/CallSiteInformation.cs
• src/NLog/Internal/DictionaryEntryEnumerable.cs
• src/NLog/Internal/ExceptionMessageFormatProvider.cs
• src/NLog/Internal/FormatHelper.cs
• src/NLog/Internal/LogMessageTemplateFormatter.cs
• src/NLog/Internal/MultiFileWatcher.cs
• src/NLog/Internal/ObjectGraphScanner.cs
• src/NLog/Internal/ObjectReflectionCache.cs
• src/NLog/Internal/PropertiesDictionary.cs
• src/NLog/Internal/PropertyHelper.cs
• src/NLog/Internal/ReflectionHelpers.cs
• src/NLog/Internal/ScopeContextAsyncState.cs
• src/NLog/Internal/SingleItemOptimizedHashSet.cs
• src/NLog/Internal/StackTraceUsageUtils.cs
• src/NLog/Internal/StringBuilderExt.cs
• src/NLog/Internal/TargetWithFilterChain.cs
• src/NLog/Internal/TimeoutContinuation.cs
• src/NLog/Internal/XmlHelper.cs
• src/NLog/LayoutRenderers/AssemblyVersionLayoutRenderer.cs
• src/NLog/LayoutRenderers/BaseDirLayoutRenderer.cs
• src/NLog/LayoutRenderers/NLogDirLayoutRenderer.cs
• src/NLog/LayoutRenderers/ProcessDirLayoutRenderer.cs
• src/NLog/LayoutRenderers/ProcessInfoLayoutRenderer.cs
• src/NLog/LayoutRenderers/StackTraceLayoutRenderer.cs
• src/NLog/LayoutRenderers/ThreadNameLayoutRenderer.cs
• src/NLog/LayoutRenderers/Wrappers/WrapLineLayoutRendererWrapper.cs
• src/NLog/Layouts/SimpleLayout.cs
• src/NLog/Layouts/Typed/Layout.cs
• src/NLog/Layouts/Typed/ValueTypeLayoutInfo.cs
• src/NLog/LogEventBuilder.cs
• src/NLog/LogEventInfo.cs
• src/NLog/LogFactory.cs
• src/NLog/LogLevelTypeConverter.cs
• src/NLog/Logger-V1Compat.cs
• src/NLog/Logger-generated.cs
• src/NLog/Logger-generated.tt
• src/NLog/Logger.cs
• src/NLog/MessageTemplates/ValueFormatter.cs
• src/NLog/ScopeContext.cs
• src/NLog/Targets/AsyncTaskTarget.cs
• src/NLog/Targets/ColoredConsoleAnsiPrinter.cs
• src/NLog/Targets/ColoredConsoleSystemPrinter.cs
• src/NLog/Targets/DefaultJsonSerializer.cs
• src/NLog/Targets/FileArchiveHandlers/BaseFileArchiveHandler.cs
• src/NLog/Targets/FileArchiveHandlers/LegacyArchiveFileNameHandler.cs
• src/NLog/Targets/FileTarget.cs
• src/NLog/Targets/LineEndingMode.cs
• src/NLog/Targets/MethodCallTarget.cs
• src/NLog/Targets/TargetWithContext.cs
• src/NLog/Targets/Wrappers/AsyncTargetWrapper.cs
• src/NLog/Targets/Wrappers/BufferingTargetWrapper.cs
• tests/NLog.RegEx.Tests/ColoredConsoleTargetTests.cs
• tests/NLog.UnitTests/LogMessageFormatterTests.cs
• tests/NLog.UnitTests/Targets/ColoredConsoleTargetTests.cs

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

425-429: Proper nullable type handling with guard clause.

The change from explicit string to inferred var correctly aligns the variable declaration with the actual return type of Path.GetDirectoryName(), which returns string?. The null/empty check guard on line 426 safely narrows the type before usage, eliminating nullable warnings while maintaining correctness.

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

96-96: LGTM! Nullable annotation aligns with Timer callback signature.

The nullable annotation correctly matches the TimerCallback delegate signature in modern .NET, which expects object? state. Since the parameter is unused in the method body, this change safely eliminates nullable warnings without any behavioral impact.

src/NLog/Targets/Wrappers/BufferingTargetWrapper.cs (1)

274-274: LGTM! Correct nullable annotation.

The parameter type change from object to object? correctly reflects that the state parameter can be null. The existing null handling on line 280 with the null-coalescing operator (?? 0) already handles this case safely.

src/NLog/LayoutRenderers/ProcessInfoLayoutRenderer.cs (1)

89-95: LGTM! Excellent null-safety improvement.

The null check for getGetMethodInfo ensures that CreateLateBoundMethod receives a valid non-null MethodInfo, preventing potential null reference issues. The explicit exception with a descriptive message improves debuggability by catching configuration errors early during initialization rather than failing later at runtime.

src/NLog/Config/MethodFactory.cs (2)

173-173: LGTM!

Using var here correctly infers the object?[] type from the updated ResolveDefaultMethodParameters return type. The downstream usages in ResolveMethodParameters overloads are already compatible.

---

208-229: Nullable annotations are correctly applied.

The changes appropriately reflect nullable semantics:

• InvokeMethodInfo returning object? aligns with MethodInfo.Invoke's nullable return type in .NET
• ResolveDefaultMethodParameters returning object?[] correctly models that ParameterInfo.DefaultValue can be null for optional parameters
• The local array on line 229 matches the return type

These align with the existing delegate signatures in MethodDetails which already use object? return types.

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

591-591: LGTM: Defensive null-safety for NET10 annotations.

The null-coalescing fallback to GetType().ToString() safely addresses nullable reference type warnings from NET10 BCL annotations. While base.ToString() should never return null in practice, this defensive guard ensures a non-null result and aligns with the PR's objective to fix nullable warnings.

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

360-362: LGTM! Proper null-safety guard added.

The null-check correctly handles cases where Convert.ToString returns null, which is possible according to .NET's nullable reference type annotations. Returning string.Empty is consistent with the exception handling behavior at line 367.

src/NLog/Targets/Wrappers/AsyncTargetWrapper.cs (1)

469-469: LGTM! Nullable annotations correctly applied.

The nullable parameter annotations on these private methods accurately reflect their actual usage patterns:

• ProcessPendingEvents receives null from the Timer constructor and never uses the state parameter
• FlushEventsInQueue safely handles nullable state with as cast and null-conditional operators
• OnRequestQueueDropItem and OnRequestQueueGrow follow standard event handler patterns where sender can be nullable

These changes improve null-safety awareness without altering behavior.

Also applies to: 523-523, 617-617, 622-622

src/NLog/Targets/AsyncTaskTarget.cs (2)

83-83: LGTM! Nullable annotations correctly applied to delegate and method.

The delegate type and method signature changes correctly reflect that the continuation state parameter can be null. The method already handles null appropriately through the cast and null-check at lines 758-762.

Also applies to: 707-707

---

786-786: LGTM! Nullable annotation correctly applied.

The nullable annotation correctly reflects that null is passed as the state parameter when initializing the timer (line 174). The unused parameter is a standard pattern for timer callbacks.

src/NLog/LayoutRenderers/StackTraceLayoutRenderer.cs (2)

173-180: LGTM: Correct nullable annotation for StackFrame.

The nullable return type correctly reflects that StackTrace.GetFrame(int) can return null when the index is out of range. This internal change improves null-safety awareness without affecting the public API.

---

197-198: LGTM: Proper null-safe handling of nullable StackFrame.

The null-conditional operator correctly handles the nullable StackFrame returned by the indexer. When a frame is null, StringBuilder.Append(null) safely appends nothing, making the raw format more defensive. This behavior aligns with AppendFlat and AppendDetailedFlat, which already skip frames without valid methods.

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

113-113: LGTM! Null-safety improvement aligns with PR objectives.

The null-coalescing guard prevents potential null reference issues when Path.GetDirectoryName returns null (e.g., for root directories or filenames without directory components in .NET 5+). Falling back to string.Empty resolves to the current directory via Path.GetFullPath, which is reasonable default behavior. Edge cases are handled gracefully by the Directory.Exists check and logging on lines 116-119.

src/NLog/LayoutRenderers/Wrappers/WrapLineLayoutRendererWrapper.cs (1)

80-80: LGTM! Conditional compilation symbol modernized.

The change from NETCOREAPP3_0_OR_GREATER to NET modernizes the conditional compilation to use the unified .NET platform symbol (5.0+). Since .NET Core 3.0+ is already covered by NETSTANDARD2_1_OR_GREATER, this change maintains equivalent behavior while aligning with modern .NET conventions.

src/NLog/Config/LoggerNameMatcher.cs (1)

187-192: Null guard enhances safety and satisfies nullable analyzer.

The added null check for both loggerName and _matchingArgument improves null safety. While _matchingArgument should never be null based on the factory method logic (Line 186 always produces a non-null substring), this defensive guard satisfies the nullable reference type analyzer and protects against potential future refactoring.

src/NLog/Config/PropertyTypeConverter.cs (1)

199-208: LGTM! Explicit null check improves nullable reference type compliance.

The explicit is null check ensures the compiler's nullable flow analysis correctly recognizes stringValue as non-null for the CultureInfo constructor at line 207. This change fixes nullable warnings without altering runtime behavior.

src/NLog/Config/LoggingConfiguration.cs (1)

118-118: LGTM! Correct nullable annotation for TryGetValue pattern.

The nullable annotation on the out Target? parameter correctly reflects that the parameter will be null when the method returns false. This aligns with standard .NET nullable reference type best practices for the TryGetValue pattern. The single call site at line 253 properly handles the nullable return value.

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

263-265: LGTM! Null-safety improvements align with PR objectives.

The null-conditional operator and null checks correctly handle properties without public getters. GetGetMethod() can return null for non-public or non-existent getters, and this change safely skips such properties in the fast lookup, preventing potential NullReferenceExceptions while satisfying nullable reference type analysis.

src/NLog/Layouts/SimpleLayout.cs (1)

191-191: The project targets net35, net46, netstandard2.0, and netstandard2.1 — not .NET Core 3.x. This change from NETCOREAPP3_0_OR_GREATER to NET has no practical impact since the project doesn't support those frameworks. The NotNullIfNotNull attribute remains applied for netstandard2.1 targets via the NETSTANDARD2_1_OR_GREATER condition, and the operator implementation correctly handles the nullable contract.

Likely an incorrect or invalid review comment.

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

109-109: Nullable warning fix is correct and appropriately aligned with the interface contract.

The change from object? to object and returning string.Empty correctly implements the IDictionaryEnumerator.Key interface signature, which defines Key as non-nullable. Returning string.Empty instead of null prevents nullable reference warnings while maintaining the contract.

Minor note: Entry.Key (from default(DictionaryEntry)) would be null, but the Key property now returns string.Empty. Since MoveNext() always returns false, this inconsistency is harmless in practice.

src/NLog/Targets/DefaultJsonSerializer.cs (4)

437-437: LGTM: Clearer null-safety check ordering.

Checking value is null before objTypeCode == TypeCode.Empty improves readability and aligns with null-safety best practices for nullable reference types.

---

444-444: LGTM: Defensive null-coalescing for ToString().

The null-coalescing guard addresses nullable reference type annotations on ToString(), even though the method should never return null for non-null String or Char values. This defensive approach ensures type safety.

---

511-519: LGTM: Null-coalescing guard for Convert.ToString().

The null-coalescing at line 515 addresses nullable annotations on Convert.ToString(), which should not return null for Enum values in practice. This ensures type safety for .NET 10 nullable reference types.

---

750-750: LGTM: Essential null-safety guard.

The null-coalescing guard is necessary here since Convert.ToString() can legitimately return null for certain object types. This prevents potential null reference issues when calling AppendStringEscape().

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

424-424: The NET conditional compilation symbol change is correct and intentional.

The symbol change from NETCOREAPP3_0_OR_GREATER to NETSTANDARD2_1_OR_GREATER || NET is verified. The NET symbol correctly represents .NET 5.0+ platforms as defined by Microsoft's compiler. This change is necessary because the guarded code uses collection expression syntax (builder.Append([...])), a C# 12 feature only available in .NET 5+. .NET Core 3.0/3.1, which reached end-of-support in 2019 and 2022 respectively, will appropriately use the fallback path with four separate Append calls. This pattern is consistent throughout the codebase (30+ occurrences) and aligns with Microsoft's deprecation of NETCOREAPP* symbols in favor of the unified NET symbol for .NET 5+.

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

750-758: LGTM! Nullable annotation aligns with .NET best practices.

The nullable parameter annotation on the Equals override correctly reflects that object.Equals can receive null. The existing type-checking logic already handles null safely by returning false.

src/NLog/Targets/FileArchiveHandlers/BaseFileArchiveHandler.cs (1)

56-59: LGTM! Null-coalescing ensures non-null directory path.

The null-coalescing guard prevents potential null propagation from Path.GetDirectoryName. The downstream method DeleteOldFilesBeforeArchive already checks for empty strings at line 69, so this change preserves existing behavior while improving null-safety.

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

246-254: LGTM! Null-coalescing aligns with method contract.

The null-coalescing operator ensures the method always returns a non-null string, consistent with the fallback at line 253. This change properly handles cases where Path.GetDirectoryName returns null for root paths or edge cases.

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

92-92: LGTM! Nullable annotation follows framework conventions.

The nullable parameter annotation correctly reflects that object.Equals accepts null inputs. The pattern matching expression (obj is AsyncLogEventInfo) safely handles null by returning false.

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

65-65: LGTM! Null-coalescing ensures non-null string result.

The guard prevents potential null returns from Convert.ToString, ensuring the method contract is honored. This aligns with other return paths in the method (lines 52, 54) that also return non-null strings.

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

242-245: LGTM! Interface implementation updated for nullable context.

The nullable parameter annotations align with the IEqualityComparer<T> interface requirements under nullable reference types. The implementation using ReferenceEquals correctly handles null inputs.

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

376-379: LGTM! Nullable annotation aligns with base class contract.

The nullable parameter annotation correctly reflects that object.Equals can receive null. The pattern matching (obj is CallSiteKey) handles null safely by returning false.

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

46-53: LGTM! Nullable parameter with consistent null handling.

The nullable Assembly? parameter combined with the null check ensures safe handling across both NETFRAMEWORK and non-NETFRAMEWORK paths. The non-NETFRAMEWORK path already used null-conditional operator (assembly?.Location), and the explicit check at lines 52-53 provides equivalent safety for the NETFRAMEWORK path.

src/NLog/Filters/WhenRepeatedFilter.cs (3)

151-151: LGTM!

Modern inline variable declaration pattern for TryGetValue. No behavioral change, just cleaner syntax.

---

381-381: LGTM!

Proper null-safety for hash code computation. When stringBuffer is null and stringValue is also null, returning 0 is the correct default hash code behavior.

---

408-411: LGTM!

Nullable annotation for Equals(object? obj) aligns with .NET nullable reference type patterns and is consistent with other Equals overrides in the codebase (e.g., LogLevel.cs, AsyncLogEventInfo.cs).

src/NLog/Config/AssemblyExtensionLoader.cs (4)

315-318: LGTM!

Defensive null-coalescing for Assembly.FullName which can be null for dynamic or in-memory assemblies. Prevents null values in the HashSet<string>.

---

328-328: LGTM!

Consistent null-coalescing for Assembly.FullName when adding to the already-registered set.

---

352-352: LGTM!

Same null-coalescing pattern applied consistently in RegisterAppDomainAssemblies.

---

398-398: LGTM!

Null-coalescing for Path.GetDirectoryName result aligns with the pattern used in PathHelpers.TrimDirectorySeparators which also handles null paths with ?? string.Empty.

src/NLog/Targets/FileArchiveHandlers/LegacyArchiveFileNameHandler.cs (1)

89-90: LGTM!

Null-coalescing for Path.GetDirectoryName ensures a non-null directory string is passed to DeleteOldFilesBeforeArchive. This is consistent with similar null-safety adjustments across the codebase.

src/NLog/Internal/ExceptionMessageFormatProvider.cs (2)

45-56: LGTM!

Nullable annotations for ICustomFormatter.Format parameters align with the interface contract in .NET. The implementation already handles null arg safely by formatting it as "{0}".

---

80-83: LGTM!

Nullable annotation for IFormatProvider.GetFormat parameter matches the .NET interface contract. The implementation returns null for unsupported format types, which is correct behavior.

src/NLog/MessageTemplates/ValueFormatter.cs (2)

266-272: LGTM!

Nullable annotation for stringValue parameter reflects that this method can receive null values. StringBuilder.Append(string?) handles null safely by appending nothing.

---

355-363: LGTM!

Nullable annotation for item parameter. The method logic handles null correctly - when item is null, it won't match IConvertible or IEnumerable, and SerializeSimpleObject will output "NULL" for null values (line 189-192).

src/NLog/Targets/FileTarget.cs (2)

1018-1018: LGTM!

Nullable annotation for timer callback's state parameter aligns with TimerCallback delegate signature which accepts nullable state.

---

1248-1248: LGTM!

Null-coalescing for Path.GetDirectoryName result ensures a non-null directory name is used in the subsequent Directory.CreateDirectory call. This prevents potential ArgumentNullException.

src/NLog/Targets/LineEndingMode.cs (3)

188-191: LGTM!

Nullable annotation for Equals(object? obj) is consistent with other Equals overrides in the codebase (e.g., LogLevel.cs line 362-365, AsyncLogEventInfo.cs line 91).

---

196-199: LGTM!

Nullable annotation for Equals(LineEndingMode? other) with proper null-conditional access other?._newLineCharacters. This matches the pattern in LogLevel.Equals(LogLevel? other) which uses other?._ordinal.

---

213-217: LGTM!

Nullable return type for ConvertFrom is correct since base.ConvertFrom can return null. The implementation properly handles the nullable name variable.

src/NLog/Internal/StackTraceUsageUtils.cs (2)

107-108: LGTM!

Null-coalescing fallback for method.ToString() is a defensive measure. While ToString() rarely returns null, this ensures the method never returns an unexpected null value.

---

219-221: LGTM!

The parameter signature change from MethodBase? to MethodBase is safe because all callers already perform null checks before invoking this method (e.g., line 250: if (method != null && LookupAssemblyFromMethod(method) != null)).

The internal logic correctly uses null-conditional access for DeclaringType?.Assembly and Module?.Assembly since these can still be null even with a non-null MethodBase.

src/NLog/Internal/CallSiteInformation.cs (2)

308-322: LGTM! Null-safety improvements are correct.

The refactoring properly handles null inputs:

• Early return when stackMethod is null prevents downstream null reference issues
• Explicit null check for declaringType before calling IsHiddenClassType eliminates potential NPEs
• The explicit return false at the end improves code clarity

---

327-332: LGTM! Minor refactor for consistency.

Inlining the declaringType variable declaration aligns with the pattern used in the updated SkipStackFrameWhenHidden method above.

src/NLog/LogLevelTypeConverter.cs (1)

46-80: LGTM! Nullable annotations align with base class.

The updated method signatures correctly adopt nullable reference type annotations to match the TypeConverter base class contract in modern .NET frameworks. The internal logic remains unchanged, and the IsNumericType helper appropriately guards against null inputs.

src/NLog/LogFactory.cs (5)

54-56: LGTM! Conditional compilation updated for broader .NET target.

The change from NETCOREAPP3_1_OR_GREATER to NET appropriately broadens the target to include all modern .NET versions (.NET 5+) while maintaining NETSTANDARD2_1_OR_GREATER for compatibility. This aligns with the availability of IAsyncDisposable across these platforms.

Also applies to: 376-411

---

288-296: LGTM! Nullable annotation for event handler parameter.

The nullable object? sender parameter aligns with standard .NET event handler patterns where the sender can be null.

---

655-655: LGTM! Fully qualified namespace prevents ambiguity.

Using NLog.Common.AsyncHelpers.PreventMultipleCalls instead of the unqualified AsyncHelpers improves code clarity and prevents potential namespace conflicts.

---

1113-1116: LGTM! Nullable annotation matches base class.

The object? parameter correctly aligns with the System.Object.Equals(object?) signature for nullable reference type compliance.

---

1227-1247: LGTM! Event handler signatures updated for null-safety.

Both OnLoggerShutdown and OnStopLogging correctly accept nullable object? sender parameters, consistent with standard .NET event handler patterns.

Also applies to: 1249-1274

src/NLog/LayoutRenderers/ProcessDirLayoutRenderer.cs (1)

84-87: LGTM! Null-coalescing guard for path operations.

The null-coalescing operator properly handles cases where Path.GetDirectoryName returns null (e.g., root directory, invalid path), ensuring _processDir is always initialized to a non-null value. This aligns with similar null-safety patterns in related layout renderers like BaseDirLayoutRenderer and NLogDirLayoutRenderer.

src/NLog/LayoutRenderers/BaseDirLayoutRenderer.cs (1)

155-158: LGTM! Consistent null-safety pattern.

The null-coalescing operator matches the pattern used in ProcessDirLayoutRenderer and ensures GetProcessDir always returns a non-null string. This prevents potential null reference issues in downstream path operations.

src/NLog/ScopeContext.cs (1)

525-529: LGTM! Defensive null-safety for ToString override.

The null-coalescing operator ensures the ToString method always returns a non-null string by falling back to the type name when _collapsed.ToString() returns null. This aligns with similar null-safety patterns throughout the PR in other ToString implementations.

src/NLog/Conditions/ConditionLiteralExpression.cs (1)

64-82: LGTM! ToString always returns non-null string.

The null-coalescing operator on line 81 ensures that Convert.ToString returning null is handled gracefully with an empty string fallback. This guarantees the ToString override always returns a non-null string, consistent with nullable reference type best practices.

src/NLog/Conditions/ConditionRelationalExpression.cs (1)

217-228: LGTM! Null-safe type promotion for comparisons.

The null-coalescing operators on lines 220 and 226 ensure that type promotions to LogLevel and string always produce non-null values, preventing null reference issues during condition evaluation. The explicit string? declaration on line 219 makes the nullable flow clear and intentional.

src/NLog/LayoutRenderers/NLogDirLayoutRenderer.cs (1)

93-93: LGTM! Null-safety improvement.

The null-coalescing operator ensures ResolveNLogDir always returns a non-null string, preventing potential null reference issues when Path.GetDirectoryName returns null.

src/NLog/Layouts/Typed/ValueTypeLayoutInfo.cs (1)

272-275: LGTM! Consistent null-safety pattern.

The null-coalescing fallback ensures ToString never returns null, aligning with similar patterns in Layout.cs and other components where type name serves as a sensible fallback.

src/NLog/Targets/ColoredConsoleSystemPrinter.cs (1)

89-94: Verify span API availability (same concern as ColoredConsoleAnsiPrinter.cs).

This change mirrors the conditional compilation update in ColoredConsoleAnsiPrinter.cs. Ensure that AsSpan is available on all target frameworks covered by the NET symbol.

src/NLog/Internal/PropertyHelper.cs (2)

175-183: LGTM! Correct Try-pattern implementation.

The logic reversal properly implements the Try-pattern by returning false when the property is not found (null) and true when found, with the result properly assigned in both cases.

---

439-439: LGTM! Defensive null check.

The explicit null check before calling IsValidPublicProperty improves null-safety and clarity, even though IsValidPublicProperty handles null internally (as shown in ReflectionHelpers.cs:182-185).

tests/NLog.UnitTests/LogMessageFormatterTests.cs (1)

103-109: Verify that production code targets match test framework coverage.

The test enables the span-based LogEventInfo path for NETSTANDARD2_1_OR_GREATER || NET. The main project targets netstandard2.1 but does not have an explicit .NET 5+ target (like net5.0, net6.0, net8.0), while the test project runs on net8.0. Confirm whether using netstandard2.1 for all .NET 5+ platforms is intentional, or if the main project should include a dedicated .NET 5+ target.

src/NLog/Conditions/ConditionExpression.cs (1)

56-58: The conditional compilation change is correct. The NET symbol is automatically defined by the .NET SDK for .NET 5.0 and later versions, all of which support the NotNullIfNotNull attribute. Combined with NETSTANDARD2_1_OR_GREATER, this condition correctly covers all target frameworks where the attribute is available (netstandard2.1 and .NET 5+), while appropriately excluding frameworks without support (net35, net46, netstandard2.0).

src/NLog/LogEventBuilder.cs (1)

123-138: The conditional compilation is correct and safely enables ReadOnlySpan<T> support across all intended targets.

The NET symbol (representing .NET 5.0 and later) is appropriate here. ReadOnlySpan is available in all .NET 5.0+ versions as well as .NET Standard 2.1, making #if NETSTANDARD2_1_OR_GREATER || NET a proper guard that correctly includes the method for frameworks that support span types while excluding those that don't (net35, net46, netstandard2.0).

Broadening from NET9_0_OR_GREATER to NET safely extends the feature to .NET 5.0, 6.0, 7.0, and 8.0 without compatibility risk.

src/NLog/Targets/ColoredConsoleAnsiPrinter.cs (1)

88-95: AsSpan is available on all frameworks covered by the condition—no action required.

The conditional #if NETSTANDARD2_1_OR_GREATER || NET correctly ensures string.AsSpan is only used where it's available:

• NETSTANDARD2_1_OR_GREATER: covers netstandard2.1 where AsSpan was introduced
• NET: covers .NET 5.0+ where AsSpan is available

Frameworks without AsSpan support (net35, net46, netstandard2.0) fall through to the #else block using the character-by-character loop, which is correct.

tests/NLog.UnitTests/Targets/ColoredConsoleTargetTests.cs (1)

389-394: LGTM! Conditional compilation symbol updated to broaden span-based API support.

The change from NETCOREAPP3_0_OR_GREATER to NETSTANDARD2_1_OR_GREATER || NET aligns with the PR's objective to enable span-based overloads under the broader NET target framework while maintaining compatibility.

tests/NLog.RegEx.Tests/ColoredConsoleTargetTests.cs (1)

167-172: LGTM! Consistent conditional compilation update.

This change mirrors the update in the main test file, ensuring span-based overloads are available under the broader NET target framework.

src/NLog/Conditions/ConditionMethods.cs (3)

79-85: LGTM! Explicit null handling improves clarity.

The explicit null check and early return make the null-handling behavior clear and explicit, aligning with the PR's nullable reference type enhancements.

---

95-101: LGTM! Consistent null handling with Contains.

The explicit null check pattern is consistently applied across string comparison methods.

---

111-117: LGTM! Completes the consistent null handling pattern.

All three string comparison methods now use the same explicit null-checking approach, improving code consistency and null-safety.

src/NLog/LayoutRenderers/AssemblyVersionLayoutRenderer.cs (1)

178-188: LGTM! Correct nullable annotation for Assembly return.

The nullable annotation accurately reflects that GetEntryAssembly() can return null. The caller GetVersion() already handles the null case via null-conditional operators (lines 157, 160, 163).

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

274-278: LGTM! Broadened NET support with collection expression syntax.

The change from NET9_0_OR_GREATER to NET enables span-based logging paths for a wider range of .NET targets. The array-literal syntax [argument] is cleaner and aligns with modern C# collection expressions.

src/NLog/Layouts/Typed/Layout.cs (4)

362-365: LGTM! Null-safe ToString with type fallback.

The null-coalescing fallback to GetType().ToString() ensures a non-null return value, aligning with similar patterns in related layout types.

---

380-396: LGTM! Nullable annotation for Equals parameter.

The nullable annotation on the obj parameter correctly reflects that Equals can receive null values.

---

401-405: LGTM! Consistent nullable annotation for generic Equals.

The nullable annotation on the typed Equals method maintains consistency with the object-based overload.

---

624-627: LGTM! Consistent ToString fallback pattern.

The null-coalescing fallback is consistently applied across layout value types, ensuring reliable string representations.

src/NLog/LayoutRenderers/ThreadNameLayoutRenderer.cs (1)

55-60: LGTM! Correct nullable annotation for thread name.

The nullable return type correctly reflects that Thread.CurrentThread.Name can be null. This aligns with the IStringValueRenderer.GetFormattedString interface signature which returns string?.

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

250-255: LGTM! Template updated to broaden NET support.

The T4 template correctly updates the conditional compilation from NET9_0_OR_GREATER to NET, and uses collection expression syntax [argument] for span-based calls. This change will propagate to all generated logging method overloads.

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

74-89: RuntimeFeature guard broadened appropriately

Using #if NETSTANDARD2_1_OR_GREATER || NET around the RuntimeFeature.IsDynamicCodeSupported check keeps the AOT-safe fallback available on all modern TFMs without changing behavior where dynamic code is supported.

src/NLog/LogEventInfo.cs (2)

136-159: Span-based overloads correctly unified under NET

Moving the ReadOnlySpan<MessageTemplateParameter> ctor and NeedToPreformatMessage(in ReadOnlySpan<object?>) under #if NETSTANDARD2_1_OR_GREATER || NET makes these span paths available on all modern TFMs that support them, with logic kept in sync with the array-based overload.

Also applies to: 675-692

---

161-186: Guarding IReadOnlyList ctor against NET35/NET40

The updated #if !NET35 && !NET40 around the IReadOnlyList<KeyValuePair<object, object?>> ctor is appropriate, since IReadOnlyList<> isn’t available on those legacy frameworks and this avoids compile-time issues there.

src/NLog/Logger.cs (2)

439-519: Generic Log<T...> overloads now using span pipeline correctly

Routing the generic single/dual/triple-argument Log<T...> overloads through WriteToTargetsWithSpan(..., [argument[..]]) under #if NETSTANDARD2_1_OR_GREATER || NET keeps behavior identical while enabling the lower-allocation span path on modern TFMs, with the existing array-based path retained for older targets.

---

571-604: New Log overloads with params ReadOnlySpan<object?> integrate cleanly

The new span-based Log overloads:

• Reuse GetTargetsForLevelSafe for enablement checks.
• Delegate directly to the internal WriteToTargetsWithSpan path.
• Leave the existing params object?[] overloads untouched for callers on older compilers/TFMs.

This is a good extension point for span-aware callers without breaking existing APIs.

Reviewing files that changed from the base of the PR and between 6cc0dc3 and b8cb19b.

• src/NLog/Common/AsyncLogEventInfo.cs
• src/NLog/Common/InternalLogger.cs
• src/NLog/Conditions/ConditionExpression.cs
• src/NLog/Conditions/ConditionLiteralExpression.cs
• src/NLog/Conditions/ConditionMethods.cs
• src/NLog/Conditions/ConditionRelationalExpression.cs
• src/NLog/Config/AssemblyExtensionLoader.cs
• src/NLog/Config/LoggerNameMatcher.cs
• src/NLog/Config/LoggingConfiguration.cs
• src/NLog/Config/MethodFactory.cs
• src/NLog/Config/PropertyTypeConverter.cs
• src/NLog/Filters/WhenRepeatedFilter.cs
• src/NLog/Internal/AppEnvironmentWrapper.cs
• src/NLog/Internal/AssemblyHelpers.cs
• src/NLog/Internal/CallSiteInformation.cs
• src/NLog/Internal/DictionaryEntryEnumerable.cs
• src/NLog/Internal/ExceptionMessageFormatProvider.cs
• src/NLog/Internal/FormatHelper.cs
• src/NLog/Internal/LogMessageTemplateFormatter.cs
• src/NLog/Internal/MultiFileWatcher.cs
• src/NLog/Internal/ObjectGraphScanner.cs
• src/NLog/Internal/ObjectReflectionCache.cs
• src/NLog/Internal/PropertiesDictionary.cs
• src/NLog/Internal/PropertyHelper.cs
• src/NLog/Internal/ReflectionHelpers.cs
• src/NLog/Internal/ScopeContextAsyncState.cs
• src/NLog/Internal/SingleItemOptimizedHashSet.cs
• src/NLog/Internal/StackTraceUsageUtils.cs
• src/NLog/Internal/StringBuilderExt.cs
• src/NLog/Internal/TargetWithFilterChain.cs
• src/NLog/Internal/TimeoutContinuation.cs
• src/NLog/Internal/XmlHelper.cs
• src/NLog/LayoutRenderers/AssemblyVersionLayoutRenderer.cs
• src/NLog/LayoutRenderers/BaseDirLayoutRenderer.cs
• src/NLog/LayoutRenderers/NLogDirLayoutRenderer.cs
• src/NLog/LayoutRenderers/ProcessDirLayoutRenderer.cs
• src/NLog/LayoutRenderers/ProcessInfoLayoutRenderer.cs
• src/NLog/LayoutRenderers/StackTraceLayoutRenderer.cs
• src/NLog/LayoutRenderers/ThreadNameLayoutRenderer.cs
• src/NLog/LayoutRenderers/Wrappers/WrapLineLayoutRendererWrapper.cs
• src/NLog/Layouts/SimpleLayout.cs
• src/NLog/Layouts/Typed/Layout.cs
• src/NLog/Layouts/Typed/ValueTypeLayoutInfo.cs
• src/NLog/LogEventBuilder.cs
• src/NLog/LogEventInfo.cs
• src/NLog/LogFactory.cs
• src/NLog/LogLevelTypeConverter.cs
• src/NLog/Logger-V1Compat.cs
• src/NLog/Logger-generated.cs
• src/NLog/Logger-generated.tt
• src/NLog/Logger.cs
• src/NLog/MessageTemplates/ValueFormatter.cs
• src/NLog/ScopeContext.cs
• src/NLog/Targets/AsyncTaskTarget.cs
• src/NLog/Targets/ColoredConsoleAnsiPrinter.cs
• src/NLog/Targets/ColoredConsoleSystemPrinter.cs
• src/NLog/Targets/DefaultJsonSerializer.cs
• src/NLog/Targets/FileArchiveHandlers/BaseFileArchiveHandler.cs
• src/NLog/Targets/FileArchiveHandlers/LegacyArchiveFileNameHandler.cs
• src/NLog/Targets/FileTarget.cs
• src/NLog/Targets/LineEndingMode.cs
• src/NLog/Targets/MethodCallTarget.cs
• src/NLog/Targets/TargetWithContext.cs
• src/NLog/Targets/Wrappers/AsyncTargetWrapper.cs
• src/NLog/Targets/Wrappers/BufferingTargetWrapper.cs
• tests/NLog.RegEx.Tests/ColoredConsoleTargetTests.cs
• tests/NLog.UnitTests/LogMessageFormatterTests.cs
• tests/NLog.UnitTests/Targets/ColoredConsoleTargetTests.cs

• src/NLog/Internal/PropertiesDictionary.cs
• src/NLog/LayoutRenderers/NLogDirLayoutRenderer.cs
• src/NLog/LayoutRenderers/ThreadNameLayoutRenderer.cs
• src/NLog/Internal/TargetWithFilterChain.cs
• src/NLog/Internal/FormatHelper.cs
• src/NLog/Targets/FileArchiveHandlers/LegacyArchiveFileNameHandler.cs
• src/NLog/Conditions/ConditionLiteralExpression.cs
• src/NLog/Common/InternalLogger.cs
• src/NLog/LogEventBuilder.cs
• src/NLog/Targets/DefaultJsonSerializer.cs
• tests/NLog.UnitTests/Targets/ColoredConsoleTargetTests.cs
• src/NLog/Targets/FileArchiveHandlers/BaseFileArchiveHandler.cs
• src/NLog/LogEventInfo.cs
• src/NLog/Config/LoggingConfiguration.cs
• tests/NLog.UnitTests/LogMessageFormatterTests.cs
• src/NLog/LogLevelTypeConverter.cs
• src/NLog/Targets/Wrappers/AsyncTargetWrapper.cs
• src/NLog/Targets/FileTarget.cs
• src/NLog/Filters/WhenRepeatedFilter.cs
• src/NLog/Internal/ObjectReflectionCache.cs
• src/NLog/Internal/ReflectionHelpers.cs
• src/NLog/Targets/TargetWithContext.cs
• src/NLog/LayoutRenderers/ProcessDirLayoutRenderer.cs
• src/NLog/Internal/PropertyHelper.cs
• src/NLog/LayoutRenderers/Wrappers/WrapLineLayoutRendererWrapper.cs
• src/NLog/LayoutRenderers/BaseDirLayoutRenderer.cs
• src/NLog/Layouts/SimpleLayout.cs
• src/NLog/Internal/ScopeContextAsyncState.cs
• src/NLog/Internal/StackTraceUsageUtils.cs
• src/NLog/Config/PropertyTypeConverter.cs
• src/NLog/LayoutRenderers/StackTraceLayoutRenderer.cs
• src/NLog/Targets/AsyncTaskTarget.cs
• src/NLog/Conditions/ConditionRelationalExpression.cs
• src/NLog/Layouts/Typed/Layout.cs
• src/NLog/Internal/AssemblyHelpers.cs

• GitHub Check: task-list-completed

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

96-99: LGTM!

The nullable annotation on the state parameter is appropriate since null is explicitly passed when constructing the Timer on line 57, and the parameter is unused in the method body.

src/NLog/Targets/Wrappers/BufferingTargetWrapper.cs (1)

274-274: LGTM! Nullable annotation aligns with actual usage.

The nullable annotation correctly reflects that the Timer callback at line 195 passes (int?)flushTimeout as state, and the existing null-safe handling at line 280 using ?? 0 ensures correct behavior.

src/NLog/ScopeContext.cs (1)

525-528: LGTM! Defensive null-safety pattern for ToString.

The addition of the null-coalescing operator ensures the method always returns a non-null string, which is essential for nullable reference type annotations. This pattern is consistent with similar ToString implementations throughout the codebase (e.g., ScopeContextAsyncState.ToString and TargetWithContext.ToString).

src/NLog/Layouts/Typed/ValueTypeLayoutInfo.cs (1)

272-275: LGTM! Null-safety improvement consistent with codebase patterns.

The addition of the null-coalescing fallback ?? GetType().ToString() correctly addresses nullable reference type warnings while maintaining consistency with similar ToString overrides in the codebase (e.g., Layout.cs lines 361-364). The fallback to the type name is appropriate and ensures a non-null return value.

src/NLog/Config/MethodFactory.cs (3)

173-173: LGTM!

Using var here correctly adapts to the nullable return type of ResolveDefaultMethodParameters. The inferred type object?[] properly flows through to downstream ResolveMethodParameters calls which already accept nullable element arrays.

---

208-221: LGTM!

The return type change to object? correctly reflects that MethodInfo.Invoke can return null (for void methods or methods that explicitly return null). This aligns with the delegate signatures in MethodDetails which already specify object? return types.

---

223-245: LGTM!

The nullable annotations are correct:

• ParameterInfo.DefaultValue (line 233) can return null for optional parameters with null defaults
• The return type object?[] properly indicates that array elements may be null
• This propagates correctly to all call sites via the var inference at line 173

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

251-251: LGTM! Null-safety fix is correct and consistent.

The null-coalescing operator appropriately handles the nullable return from Path.GetDirectoryName, ensuring a non-null string is returned. This fix aligns with the nullable reference type annotations and matches the defensive pattern used throughout this file.

src/NLog/Targets/LineEndingMode.cs (3)

188-191: LGTM! Nullable parameter handled correctly.

The nullable annotation on the parameter is appropriate, and the implementation correctly handles null values using pattern matching, which returns false when obj is null. This pattern aligns with similar changes in LogLevel.cs.

---

196-199: LGTM! Nullable parameter handled correctly.

The nullable annotation is appropriate, and the implementation correctly handles null values using the null-conditional operator (other?._newLineCharacters). This pattern is consistent with similar implementations in LogLevel.cs.

---

213-217: LGTM! Nullable return type is appropriate.

The nullable return type annotation correctly reflects that base.ConvertFrom(context, culture, value) can return null when the conversion is not supported. This matches the same pattern used in LogLevelTypeConverter.ConvertFrom.

src/NLog/Conditions/ConditionMethods.cs (1)

81-84: Null safety improvement, verify intended behavior for null inputs.

The explicit null guards improve safety by preventing exceptions. However, please verify that returning false for null inputs aligns with the intended semantics—particularly edge cases like whether null should be considered to contain null.

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

360-362: LGTM! Proper null-safety guard added.

The null check correctly handles the case where Convert.ToString returns null, which aligns with .NET nullable reference type annotations. The early return with string.Empty is consistent with the catch block's fallback behavior.

src/NLog/LogFactory.cs (5)

54-56: LGTM: Standard IAsyncDisposable pattern.

The conditional compilation and interface addition follow the standard .NET pattern for async disposal support.

---

288-288: LGTM: Nullable sender annotation.

The nullable sender parameter aligns with standard .NET event handler conventions and nullable reference type best practices.

---

655-655: LGTM: Namespace qualification.

Explicit namespace qualification improves code clarity and helps with disambiguation.

---

1113-1116: LGTM: Standard Equals nullable override.

The nullable parameter annotation correctly reflects the standard Object.Equals signature and the implementation safely handles null/non-matching types.

---

1227-1247: LGTM: Event handler nullable sender annotations.

The nullable sender parameters are correct for event handlers and consistent with the actual usage on Line 1231 where null is explicitly passed as the sender.

Also applies to: 1249-1274

src/NLog/Internal/CallSiteInformation.cs (3)

310-311: LGTM! Good defensive null guard.

The early null check prevents potential NullReferenceException on subsequent property accesses and aligns with the PR's null safety objectives. Returning true (skip frame) when the method cannot be determined is the correct behavior.

---

317-321: LGTM! Explicit null handling improves safety and clarity.

The explicit null check for declaringType before calling IsHiddenClassType prevents violating the method's non-nullable contract (line 52). The logic correctly handles the edge case where DeclaringType is null by not skipping the frame (since we cannot determine if it's hidden). The explicit return false on line 321 makes the control flow clearer.

---

329-329: LGTM! Proper null-safe handling.

The null-conditional operator stackMethod?.DeclaringType combined with the null check ensures safe execution even if stackMethod is null. While the call site at line 253 ensures stackMethod is non-null when this method is invoked, this defensive approach correctly honors the method's nullable signature.

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

113-113: Null-safety guard is appropriate and consistent with the codebase.

The ?? string.Empty addition correctly handles the nullable return from Path.GetDirectoryName and aligns with the PR's null-safety objectives. This pattern is used consistently throughout the codebase in similar contexts (ProcessDirLayoutRenderer, BaseDirLayoutRenderer, FileTarget, and file archive handlers). The subsequent Directory.Exists check on line 116 validates the directory, making the approach safe even when GetDirectoryName returns null for edge cases like bare filenames without directory components.

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

242-245: LGTM! Nullable annotation correctly applied.

The updated signature for IEqualityComparer<T>.Equals now accepts nullable parameters, which aligns with .NET nullable reference type conventions. The ReferenceEquals implementation correctly handles null inputs.

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

92-92: LGTM! Standard nullable annotation for Equals override.

The parameter is now correctly annotated as nullable, matching the base object.Equals(object?) signature. The pattern matching implementation handles null inputs correctly.

src/NLog/MessageTemplates/ValueFormatter.cs (2)

266-272: LGTM! StringBuilder safely handles nullable strings.

The nullable annotation is appropriate here. StringBuilder.Append correctly handles null strings by treating them as empty, and the calling context at Line 203 can pass a nullable result from IConvertible.ToString().

---

355-363: LGTM! Null handling is correct.

The nullable annotation is appropriate. The pattern matching checks (is IConvertible, is IEnumerable) correctly return false for null items, and SerializeSimpleObject handles null explicitly at Line 189.

src/NLog/LayoutRenderers/AssemblyVersionLayoutRenderer.cs (1)

178-188: LGTM! Nullable return type accurately reflects Assembly.GetEntryAssembly behavior.

The nullable annotation is correct. Assembly.GetEntryAssembly() can return null in certain hosting scenarios (e.g., unmanaged hosts), and the caller at Line 152 properly handles this with null-conditional operators.

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

424-432: No changes needed. The preprocessor condition is correct and safe.

The code uses a defensive conditional compilation strategy: the collection expression syntax [...] is guarded behind #if NETSTANDARD2_1_OR_GREATER || NET, which only activates for targets that support C# 12+. For netstandard2.1, the project explicitly sets LangVersion=13 (C# 13), so collection expressions are fully supported. All other targets (net35, net46, netstandard2.0) fall through to the #else block, which uses individual Append() calls without collection expressions. The NET symbol is unused for current target frameworks (which don't include .NET 5+), making this change future-proof rather than problematic.

Likely an incorrect or invalid review comment.

src/NLog/Conditions/ConditionExpression.cs (1)

56-58: Change is correct and follows established patterns.

The NotNullIfNotNull attribute is available in .NET Standard 2.1 and later, so the conditional compilation #if NETSTANDARD2_1_OR_GREATER || NET correctly applies the attribute only where the framework provides it. This pattern is already used consistently in SimpleLayout.cs and appropriately handles NLog's multi-framework targeting (net35, net46, netstandard2.0, netstandard2.1, and NET 5.0+).

src/NLog/Targets/ColoredConsoleAnsiPrinter.cs (1)

88-88: Conditional broadened to include all .NET targets.

The change from NETCOREAPP3_0_OR_GREATER to NET expands the span-based write path to all .NET 5+ targets, aligning with the PR's goal of broadening NET-targeted code paths. The Span APIs are available in both target sets, so this is functionally correct.

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

96-376: Span-based routing for V1 compat overloads looks consistent

All the updated Log/Trace/Debug/Info/Warn/Error/Fatal overloads that now call WriteToTargetsWithSpan(..., [args]) under #if NETSTANDARD2_1_OR_GREATER || NET (with WriteToTargets(..., new object?[]{...}) in the #else) preserve the prior exception/formatProvider/culture and level gating semantics while aligning with the core span pipeline in Logger. I don’t see functional or overload-resolution issues in these compat shims.

Also applies to: 714-1154, 1297-1840, 1888-2427, 2475-3014, 3058-3601, 3649-4188

src/NLog/Targets/ColoredConsoleSystemPrinter.cs (1)

87-93: Broadening span-based WriteSubString path to all NET targets

Switching the guard to #if NETSTANDARD2_1_OR_GREATER || NET means the AsSpan/Write(ReadOnlySpan<char>) path is used on all modern .NET / .NET Core TFMs, with Substring kept as the fallback. That’s a good perf win and should be safe given those APIs are available wherever NET is defined. Please just confirm your targeted TFMs all meet that requirement.

tests/NLog.RegEx.Tests/ColoredConsoleTargetTests.cs (1)

167-172: Span overload override keeps tests aligned with production writer

Adding Write(ReadOnlySpan<char> buffer) to PartsWriter under #if NETSTANDARD2_1_OR_GREATER || NET nicely tracks the production change to use TextWriter.Write(ReadOnlySpan<char>), so the tests still capture the same segments for both string and span writes. Just ensure all TFMs where this test is built expose that virtual overload on StringWriter.

src/NLog/Logger.cs (2)

571-604: New params ReadOnlySpan<object?> Log overloads – check language version and binding impact

Introducing

public void Log(LogLevel level, string message, params ReadOnlySpan<object?> args)
public void Log(LogLevel level, Exception? exception, string message, params ReadOnlySpan<object?> args)

under #if NETSTANDARD2_1_OR_GREATER || NET is a good way to gain span-based params perf benefits, but it assumes the code is compiled with a C# version that supports params on non-array collections (notably ReadOnlySpan<T>).(developers.redhat.com)

Also, with both params object?[] and params ReadOnlySpan<object?> overloads in scope, C# 13+ overload resolution prefers the span overload when both are applicable, which can be a behavioral change versus earlier compilers, especially inside expression trees.(learn.microsoft.com) That seems intentional and aligns with the BCL, but it’s worth double-checking that any callers relying on expression-tree capture of Logger.Log are OK with the new binding.

---

440-471: Span-based internal pipeline matches existing behavior and looks correct

The updated generic Log<TArgument[1..3]> overloads and the internal WriteToTargetsWithSpan/RenderPreformattedLogEvent pipeline:

• Share the same GetTargetsForLevelSafe / GetTargetsForLevel gating as the object[] path.
• Use NeedToPreformatMessage(args) and AutoMessageTemplateFormatter consistently, only allocating arrays via args.ToArray() when necessary (empty span, preformat fallback, or template parse failure).
• Don’t let the ReadOnlySpan<object?> escape the call stack; spans are only used synchronously within these methods, so there are no lifetime issues.

Given that, the refactor to route the generic and compat overloads through the span-based path under NETSTANDARD2_1_OR_GREATER || NET looks sound and backwards compatible aside from the expected params-overload binding differences noted earlier.

Also applies to: 484-518, 533-569, 606-642, 644-668

Reviewing files that changed from the base of the PR and between b8cb19b and ae86481.

• src/NLog/Common/AsyncLogEventInfo.cs
• src/NLog/Common/InternalLogger.cs
• src/NLog/Conditions/ConditionExpression.cs
• src/NLog/Conditions/ConditionLiteralExpression.cs
• src/NLog/Conditions/ConditionMethods.cs
• src/NLog/Conditions/ConditionRelationalExpression.cs
• src/NLog/Config/AssemblyExtensionLoader.cs
• src/NLog/Config/LoggerNameMatcher.cs
• src/NLog/Config/LoggingConfiguration.cs
• src/NLog/Config/MethodFactory.cs
• src/NLog/Config/PropertyTypeConverter.cs
• src/NLog/Filters/WhenRepeatedFilter.cs
• src/NLog/Internal/AppEnvironmentWrapper.cs
• src/NLog/Internal/AssemblyHelpers.cs
• src/NLog/Internal/CallSiteInformation.cs
• src/NLog/Internal/DictionaryEntryEnumerable.cs
• src/NLog/Internal/ExceptionMessageFormatProvider.cs
• src/NLog/Internal/FormatHelper.cs
• src/NLog/Internal/LogMessageTemplateFormatter.cs
• src/NLog/Internal/MultiFileWatcher.cs
• src/NLog/Internal/ObjectGraphScanner.cs
• src/NLog/Internal/ObjectReflectionCache.cs
• src/NLog/Internal/PropertiesDictionary.cs
• src/NLog/Internal/PropertyHelper.cs
• src/NLog/Internal/ReflectionHelpers.cs
• src/NLog/Internal/ScopeContextAsyncState.cs
• src/NLog/Internal/SingleItemOptimizedHashSet.cs
• src/NLog/Internal/StackTraceUsageUtils.cs
• src/NLog/Internal/StringBuilderExt.cs
• src/NLog/Internal/TargetWithFilterChain.cs
• src/NLog/Internal/TimeoutContinuation.cs
• src/NLog/Internal/XmlHelper.cs
• src/NLog/LayoutRenderers/AssemblyVersionLayoutRenderer.cs
• src/NLog/LayoutRenderers/BaseDirLayoutRenderer.cs
• src/NLog/LayoutRenderers/NLogDirLayoutRenderer.cs
• src/NLog/LayoutRenderers/ProcessDirLayoutRenderer.cs
• src/NLog/LayoutRenderers/ProcessInfoLayoutRenderer.cs
• src/NLog/LayoutRenderers/StackTraceLayoutRenderer.cs
• src/NLog/LayoutRenderers/ThreadNameLayoutRenderer.cs
• src/NLog/LayoutRenderers/Wrappers/WrapLineLayoutRendererWrapper.cs
• src/NLog/Layouts/SimpleLayout.cs
• src/NLog/Layouts/Typed/Layout.cs
• src/NLog/Layouts/Typed/ValueTypeLayoutInfo.cs
• src/NLog/LogEventBuilder.cs
• src/NLog/LogEventInfo.cs
• src/NLog/LogFactory.cs
• src/NLog/LogLevelTypeConverter.cs
• src/NLog/Logger-V1Compat.cs
• src/NLog/Logger-generated.cs
• src/NLog/Logger-generated.tt
• src/NLog/Logger.cs
• src/NLog/MessageTemplates/ValueFormatter.cs
• src/NLog/ScopeContext.cs
• src/NLog/Targets/AsyncTaskTarget.cs
• src/NLog/Targets/ColoredConsoleAnsiPrinter.cs
• src/NLog/Targets/ColoredConsoleSystemPrinter.cs
• src/NLog/Targets/DefaultJsonSerializer.cs
• src/NLog/Targets/FileArchiveHandlers/BaseFileArchiveHandler.cs
• src/NLog/Targets/FileArchiveHandlers/LegacyArchiveFileNameHandler.cs
• src/NLog/Targets/FileTarget.cs
• src/NLog/Targets/LineEndingMode.cs
• src/NLog/Targets/MethodCallTarget.cs
• src/NLog/Targets/TargetWithContext.cs
• src/NLog/Targets/Wrappers/AsyncTargetWrapper.cs
• src/NLog/Targets/Wrappers/BufferingTargetWrapper.cs
• tests/NLog.RegEx.Tests/ColoredConsoleTargetTests.cs
• tests/NLog.UnitTests/LogMessageFormatterTests.cs
• tests/NLog.UnitTests/Targets/ColoredConsoleTargetTests.cs

• src/NLog/Targets/FileArchiveHandlers/BaseFileArchiveHandler.cs
• src/NLog/LayoutRenderers/AssemblyVersionLayoutRenderer.cs
• src/NLog/LayoutRenderers/ProcessDirLayoutRenderer.cs
• src/NLog/Targets/MethodCallTarget.cs
• src/NLog/LayoutRenderers/ProcessInfoLayoutRenderer.cs
• src/NLog/Internal/XmlHelper.cs
• src/NLog/Targets/Wrappers/BufferingTargetWrapper.cs
• src/NLog/Config/LoggingConfiguration.cs
• src/NLog/LayoutRenderers/BaseDirLayoutRenderer.cs
• src/NLog/LayoutRenderers/ThreadNameLayoutRenderer.cs
• src/NLog/Common/AsyncLogEventInfo.cs
• src/NLog/Targets/AsyncTaskTarget.cs
• src/NLog/Targets/FileTarget.cs
• tests/NLog.UnitTests/Targets/ColoredConsoleTargetTests.cs
• src/NLog/Config/AssemblyExtensionLoader.cs
• src/NLog/Targets/ColoredConsoleAnsiPrinter.cs
• src/NLog/Filters/WhenRepeatedFilter.cs
• src/NLog/Internal/FormatHelper.cs
• src/NLog/Config/PropertyTypeConverter.cs
• src/NLog/Config/LoggerNameMatcher.cs
• src/NLog/Targets/DefaultJsonSerializer.cs
• src/NLog/LogLevelTypeConverter.cs
• src/NLog/Internal/AppEnvironmentWrapper.cs
• src/NLog/Internal/ExceptionMessageFormatProvider.cs
• src/NLog/Common/InternalLogger.cs
• src/NLog/Internal/SingleItemOptimizedHashSet.cs
• src/NLog/Internal/StringBuilderExt.cs
• src/NLog/Internal/StackTraceUsageUtils.cs
• src/NLog/Internal/ObjectGraphScanner.cs
• src/NLog/Internal/LogMessageTemplateFormatter.cs
• src/NLog/Internal/PropertiesDictionary.cs
• src/NLog/Internal/ReflectionHelpers.cs
• src/NLog/Internal/TargetWithFilterChain.cs
• src/NLog/Internal/ObjectReflectionCache.cs
• src/NLog/Internal/PropertyHelper.cs

• GitHub Check: task-list-completed

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

96-96: LGTM! Correct nullable annotation for Timer callback.

The nullable annotation on the state parameter is appropriate since the Timer is constructed with null as the state value (line 57), and the parameter is unused within the method body.

src/NLog/Targets/LineEndingMode.cs (3)

188-191: LGTM! Nullable annotation correctly applied.

The nullable annotation on the object? parameter is appropriate, and the implementation correctly handles null values via pattern matching.

---

196-199: LGTM! Nullable annotation and null-safe implementation.

The nullable annotation correctly reflects that the method can accept null, and the implementation safely handles null values using the null-conditional operator.

---

213-217: LGTM! Nullable return type correctly reflects base class behavior.

The nullable return type annotation is appropriate since base.ConvertFrom can potentially return null, making this override correctly reflect the actual return possibilities.

src/NLog/LayoutRenderers/NLogDirLayoutRenderer.cs (1)

93-93: LGTM!

The null-coalescing operator correctly handles the case where Path.GetDirectoryName returns null (e.g., for root paths), ensuring the method always returns a non-null string as expected by the return type.

src/NLog/LayoutRenderers/Wrappers/WrapLineLayoutRendererWrapper.cs (1)

80-84: LGTM!

The updated preprocessor directive correctly expands the Span-based optimization to all modern .NET (5+) targets. The NET symbol is defined for .NET 5 and later, which all support StringBuilder.Append(ReadOnlySpan<char>), making this a valid broadening of the optimized code path.

src/NLog/LayoutRenderers/StackTraceLayoutRenderer.cs (2)

173-180: LGTM!

The nullable return type StackFrame? correctly reflects the reality that StackTrace.GetFrame() can return null in certain scenarios (e.g., .NET Native, heavily optimized code). This aligns with the .NET 10 nullable annotations and makes the API contract explicit.

---

197-198: LGTM!

The null-conditional operator f?.ToString() properly handles potential null frames. When f is null, Append(null) simply appends nothing, maintaining the existing behavior while satisfying nullable analysis.

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

108-110: Pragmatic nullable fix, but note the minor inconsistency.

The change to return string.Empty for Key satisfies the non-nullable annotation from .NET 10. However, this creates a subtle inconsistency: Entry.Key (from the default DictionaryEntry struct) remains null, while the Key property now returns string.Empty.

This is acceptable because:

1. MoveNext() always returns false, so these properties should never be accessed in correct enumeration patterns.
2. Allocating a new DictionaryEntry just for consistency would be unnecessary overhead for an empty enumerator.

src/NLog/Internal/CallSiteInformation.cs (2)

310-321: LGTM! Improved null safety handling.

The refactored null checks properly handle nullable reference types:

• Explicit null check for stackMethod at the start ensures safe access to its members
• Defensive check for declaringType before calling IsHiddenClassType
• Explicit return false statement improves code clarity

These changes align well with the PR objective of fixing nullable warnings from NET10 annotations.

---

329-329: LGTM! Proper use of null-conditional operator.

The null-conditional operator ?. correctly handles the case where stackMethod might be null, aligning with nullable reference type best practices in .NET.

src/NLog/ScopeContext.cs (1)

525-528: LGTM! Null-safe ToString() implementation.

The addition of the GetType().ToString() fallback ensures this method never returns null, addressing nullable warnings from NET10 annotations. This pattern is consistent with similar implementations elsewhere in the codebase.

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

586-592: LGTM! Null-safe ToString() fallback.

The addition of the GetType().ToString() fallback in the else branch ensures this method never returns null, addressing nullable warnings from NET10 annotations. This is consistent with the same pattern applied in ScopeContext.cs line 527.

src/NLog/Targets/Wrappers/AsyncTargetWrapper.cs (4)

469-469: LGTM! Nullable annotation aligns with framework delegate signature.

The nullable annotation on the state parameter correctly matches the TimerCallback delegate signature in .NET, which expects object? state. This change improves null-safety compliance without affecting behavior.

---

523-523: LGTM! Nullable annotation aligns with framework delegate signature.

The nullable annotation on the state parameter correctly matches the WaitCallback delegate signature. The method safely handles null values using the as operator (line 525) and null checks (line 531).

---

617-620: LGTM! Nullable annotation aligns with framework event handler signature.

The nullable annotation on the sender parameter correctly matches the EventHandler<LogEventDroppedEventArgs> delegate signature in .NET, where sender is nullable. This change improves null-safety compliance.

---

622-625: LGTM! Nullable annotation aligns with framework event handler signature.

The nullable annotation on the sender parameter correctly matches the EventHandler<LogEventQueueGrowEventArgs> delegate signature in .NET, where sender is nullable. This change improves null-safety compliance.

src/NLog/LogEventBuilder.cs (1)

123-123: LGTM! Conditional compilation broadened appropriately.

The change from NET9_0_OR_GREATER to NET correctly broadens the availability of the Properties(ReadOnlySpan<(string, object?)>) overload to all .NET 5.0+ targets, since this method doesn't use the params modifier with ReadOnlySpan. This is intentionally different from line 253, which correctly retains NET9_0_OR_GREATER because the params modifier with ReadOnlySpan requires C# 13 (.NET 9.0+).

src/NLog/Layouts/Typed/Layout.cs (4)

362-365: LGTM! Defensive null-coalescing in ToString.

The null-coalescing operator ensures ToString() never returns null, which aligns with nullable reference type best practices and is consistent with similar patterns throughout the codebase.

---

380-396: LGTM! Correct nullable annotation for Equals override.

The nullable annotation on the obj parameter is the correct signature for overriding Object.Equals and aligns with .NET nullable reference type conventions. The implementation properly handles null values.

---

401-405: LGTM! Appropriate nullable annotation for IEquatable.

The nullable annotation on the other parameter is appropriate for IEquatable<T> where T might be nullable. The implementation correctly handles null values using object.Equals.

---

624-627: LGTM! Consistent defensive null-coalescing.

The null-coalescing operator is consistent with the pattern used in FuncMethodValue.ToString() (line 364) and ensures the method never returns null.

src/NLog/Layouts/Typed/ValueTypeLayoutInfo.cs (1)

272-275: LGTM! Consistent null-coalescing pattern.

The null-coalescing operator follows the same defensive pattern used in Layout.cs (lines 364 and 626), ensuring ToString() never returns null. This change is consistent with the PR objective to fix nullable warnings from .NET nullable reference type annotations.

src/NLog/MessageTemplates/ValueFormatter.cs (2)

266-272: LGTM! Nullable annotation correctly added.

The signature change from string to string? appropriately reflects that the method can receive null values (e.g., from IConvertible.ToString() at line 203). The implementation safely handles null since StringBuilder.Append(string?) treats null as an empty string.

---

355-363: LGTM! Nullable annotation correctly added.

The signature change from object to object? appropriately reflects that collection items (dictionary keys, values, or list elements) can be null. The implementation correctly handles null through the cascading checks—ultimately reaching SerializeSimpleObject which appends "NULL" (lines 189-193).

src/NLog/Conditions/ConditionExpression.cs (1)

56-58: LGTM! Conditional compilation updated for modern .NET targets.

The change from NETCOREAPP3_0_OR_GREATER to NET appropriately broadens support to all modern .NET versions (5+) while maintaining .NET Standard 2.1+ compatibility. The NotNullIfNotNull attribute is available in both target groups.

src/NLog/Conditions/ConditionMethods.cs (3)

81-84: LGTM! Null safety improved.

The explicit null checks prevent exceptions and provide sensible fallback behavior (returning false when either operand is null).

---

97-100: LGTM! Null safety improved.

Consistent with the Contains method, this prevents exceptions when either parameter is null.

---

113-116: LGTM! Null safety improved.

Consistent with the other string predicate methods, this prevents exceptions when either parameter is null.

src/NLog/Conditions/ConditionRelationalExpression.cs (2)

219-220: LGTM! Null-safe LogLevel conversion.

The intermediate variable and null-coalescing operator ensure LogLevel.FromString receives a non-null argument, preventing potential exceptions when Convert.ToString returns null.

---

226-226: LGTM! Null-safe string promotion.

The null-coalescing operator ensures type promotion to string always produces a non-null value, aligning with nullable reference type expectations.

src/NLog/Conditions/ConditionLiteralExpression.cs (1)

81-81: LGTM! Ensures non-null return value.

The null-coalescing operator guarantees ToString() always returns a non-null string, satisfying the method signature contract when Convert.ToString returns null for edge cases.

src/NLog/Targets/TargetWithContext.cs (1)

727-730: LGTM! Nullable warning properly addressed.

The implementation correctly ensures a non-null return value through the triple fallback chain. While the final ?? GetType().ToString() is technically redundant since base.ToString() never returns null, the defensive approach is good practice and aligns with the PR's objective to fix nullable warnings from NET10 annotations.

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

113-113: Null-safety improvement approved.

The null-coalescing operator appropriately handles the nullable return value from Path.GetDirectoryName, ensuring type-safe behavior for downstream calls to Path.GetFullPath and Directory.Exists. The existing exception handling at lines 127-132 provides additional protection.

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

46-50: No changes needed - nullable parameter change is correct and all callers are compatible.

The nullable annotation on the assembly parameter correctly aligns with .NET nullable reference types. The implementation safely handles null input in both code paths (lines 50 and 52-53), and all five callers are compatible with this signature change. Two callers pass Assembly.GetEntryAssembly() which can legitimately be null, and three callers pass typeof(...).Assembly which is never null—both patterns work correctly with the nullable parameter.

src/NLog/Targets/ColoredConsoleSystemPrinter.cs (1)

89-89: The original concern about excluding .NET Core 3.0/3.1 from the AsSpan path is not applicable—the project targets only net35, net46, netstandard2.0, and netstandard2.1, not any .NET Core versions. The change from NETCOREAPP3_0_OR_GREATER to NET has no impact on supported frameworks, as neither directive activates in the current build matrix. Only the NETSTANDARD2_1_OR_GREATER part of the condition is effective for existing targets.

Likely an incorrect or invalid review comment.

src/NLog/Targets/FileArchiveHandlers/LegacyArchiveFileNameHandler.cs (1)

89-90: Null-safety improvement is correct.

The null-coalescing operator properly addresses the nullable warning. The DeleteOldFilesBeforeArchive method in the parent class explicitly handles the empty directory case by returning false (line 18-19 in BaseFileArchiveHandler.cs), so passing an empty string is safe.

src/NLog/LogEventInfo.cs (3)

161-161: LGTM: Correct API availability guard.

The additional !NET40 exclusion is appropriate since IReadOnlyList<T> was introduced in .NET Framework 4.5 and is not available in .NET Framework 4.0. This change ensures the constructor is only available on platforms that support the required API.

---

675-675: LGTM: Consistent conditional compilation broadening.

The change from NET9_0_OR_GREATER to NET broadens the availability of the ReadOnlySpan<object?> overload of NeedToPreformatMessage to all .NET 5.0+ targets, which is consistent with the change on line 136. Since ReadOnlySpan<T> is supported in all .NET 5.0+ targets, this change is appropriate.

The verification script provided for line 136 will also validate this change.

---

136-136: The conditional compilation changes are correct and safe.

The NET preprocessor symbol is defined only for .NET 5.0+ (the unified platform) and does not include older .NET Framework versions (net35, net46). The pattern NETSTANDARD2_1_OR_GREATER || NET correctly enables these code paths only on platforms that support ReadOnlySpan<T>:

• .NET Standard 2.1+ (includes netstandard2.1)
• .NET 5.0+ (unified platform)

This correctly excludes net35 and net46, which lack ReadOnlySpan<T> support. The additional !NET40 exclusion at line 161 is also correct, as IReadOnlyList<T> was introduced in .NET Framework 4.5, not 4.0.

src/NLog/Config/MethodFactory.cs (3)

173-173: LGTM: Appropriate use of type inference.

Using var here correctly accommodates the new nullable return type (object?[]) from ResolveDefaultMethodParameters while maintaining readability.

---

208-221: LGTM: Correct nullable return type.

Changing the return type from object to object? accurately reflects that MethodInfo.Invoke can return null, improving null-safety annotations without altering behavior.

---

223-245: LGTM: Correct nullable array type for optional parameters.

The return type change from object[] to object?[] and the corresponding array instantiation on line 229 correctly reflect that optional parameters can have null as their default value (line 233). This aligns well with the existing delegate signatures in MethodDetails.

src/NLog/LogFactory.cs (6)

288-288: LGTM: Correct nullable annotation for event handler.

The nullable sender parameter aligns with the standard EventHandler<T> pattern where the sender can be null.

---

376-411: LGTM: Async disposal implementation with timeout.

The DisposeAsync implementation properly flushes before disposing and uses a timeout to prevent indefinite blocking. Note that if the timeout expires (line 402), the background DisposeInternal task will continue running but the method returns. This is acceptable for disposal scenarios where blocking indefinitely is worse than allowing background cleanup to complete.

---

1113-1116: LGTM: Correct override signature with nullable parameter.

The nullable obj parameter matches the base Object.Equals(object?) signature and is properly handled by the pattern matching on line 1115.

---

1227-1247: LGTM: Correct nullable annotation for event handler.

The nullable sender parameter is appropriate for the event handler pattern and matches the usage on line 1231 where null is explicitly passed as the sender.

---

1249-1274: LGTM: Correct nullable annotation for event handler.

The nullable sender parameter aligns with the event handler pattern and is consistent with the OnLoggerShutdown method signature.

---

54-56: The NET preprocessor symbol is non-standard and undefined in the project configuration.

The conditional compilation uses || NET, but this bare symbol is not a Microsoft standard preprocessor symbol (standard symbols are version-specific like NET5_0_OR_GREATER, NET6_0_OR_GREATER). The symbol is also not explicitly defined in NLog.csproj. Since NET is undefined, the condition #if NETSTANDARD2_1_OR_GREATER || NET effectively only matches when compiling for .NET Standard 2.1, not for other target frameworks (net35, net46, netstandard2.0).

Define the NET symbol explicitly in the project configuration if it's intended as a catch-all for modern .NET versions, or use version-specific symbols instead.

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

269-389: Trace span-based overload routing looks consistent

Trace generic overloads now delegate to WriteToTargetsWithSpan under NETSTANDARD2_1_OR_GREATER || NET with [argument] / [arg1, arg2, arg3] and fall back to new object?[] { ... } otherwise. The guards and culture handling are preserved; routing is consistent and safe.

---

562-681: Debug span-based overload routing matches Trace pattern

Debug generic overloads mirror the Trace changes: same IsDebugEnabled guards, same culture arguments, and [argument...] span packaging behind NETSTANDARD2_1_OR_GREATER || NET, with object-array fallback otherwise. No functional regressions spotted.

---

854-973: Info span-based overloads correctly expanded to NET

Info generic overloads are updated to use span-based routing under NETSTANDARD2_1_OR_GREATER || NET and maintain the existing object-array path for older targets. Argument order, culture handling, and enable checks remain unchanged.

---

1146-1265: Warn generic overloads span-routing is coherent with other levels

Warn generic overloads follow the same pattern as Trace/Debug/Info: the only change is how arguments are packaged ([arg...] vs new object?[]{...}). Control flow and observable behavior are preserved.

---

1438-1557: Error generic overloads: span vs array paths correctly conditioned

Error generic overloads now use WriteToTargetsWithSpan with [argument...] when NETSTANDARD2_1_OR_GREATER || NET is defined and otherwise fall back to WriteToTargets with new object?[]{...}. Logging level checks and message/formatProvider wiring are intact.

---

1730-1849: Fatal generic overloads: span-based argument packaging applied consistently

Fatal generic overloads are updated in line with the other levels; only the last argument is re-shaped into [argument...] for the span-based path, guarded by NETSTANDARD2_1_OR_GREATER || NET. No API or behavioral change beyond allocation strategy.

src/NLog/Logger-V1Compat.cs (19)

96-133: Log(level, message, arg1/arg2/arg3) compat overloads: span calls are correct

The Log overloads using GetTargetsForLevelSafe now delegate to WriteToTargetsWithSpan(..., [arg1, arg2] / [arg1, arg2, arg3]) under NETSTANDARD2_1_OR_GREATER || NET, with an object-array fallback otherwise. This mirrors the main Logger implementation and preserves behavior while enabling the span path.

---

264-297: Log(level, ..., string? argument) overload: widened to span path correctly

The string?-argument Log overload now uses WriteToTargetsWithSpan(level, null, formatProvider, message, [argument]) when NETSTANDARD2_1_OR_GREATER || NET is defined, and retains the new object?[]{ argument } path otherwise. The IsEnabled(level) guard and formatting semantics remain unchanged.

---

506-541: Log(level, ..., object? argument) overload: targetsForLevel span routing looks good

For object? argument, the method now calls WriteToTargetsWithSpan(targetsForLevel, level, null, formatProvider, message, [argument]) under NET, with a new object?[] { argument } fallback. This avoids re-looking up targets and matches the span-based helper’s contract.

---

714-748: Trace V1 overloads (2–3 args) correctly updated to span path

The binary-compat Trace overloads with 2 and 3 object? arguments now route through WriteToTargetsWithSpan(LogLevel.Trace, ..., [arg1, arg2/arg3]) for NET targets, preserving the existing IsTraceEnabled guard and default culture. Fallback behavior for non-NET targets is unchanged.

---

872-904: Trace(string? / object? argument) overloads: span packaging is consistent

The Trace overloads taking a single string? or object? argument use the same [argument] span packaging pattern under NETSTANDARD2_1_OR_GREATER || NET and still allocate new object?[]{ argument } otherwise. No change in logging semantics, only in argument transport.

---

1297-1335: Debug V1 overloads (2–3 args) match the updated span pattern

For Debug with 2–3 object? arguments, the updated implementations use WriteToTargetsWithSpan(LogLevel.Debug, ..., [arg1, arg2/arg3]) under NET, with the original object-array path retained for older targets. Guards and culture usage are preserved.

---

1459-1491: Debug(string? / object? argument) overloads: span usage mirrors Trace/Info

The single-argument Debug overloads now follow the same span-based routing as Trace/Info: [argument] for NET, new object?[]{ argument } otherwise. This keeps the overload set coherent and doesn’t change public behavior.

---

1888-1922: Info V1 overloads (2–3 args) span-based routing is aligned

Info overloads with 2–3 object? arguments now call WriteToTargetsWithSpan(LogLevel.Info, ..., [arg1, arg2/arg3]) when NET is available. The previous new object?[]{...} array creation is retained in the #else branch. Everything else (guards, culture) stays as before.

---

2050-2078: Info(string? argument) V1 overloads: span packaging looks correct

For the Info overloads that take a single string? argument (with and without formatProvider), the span-based path under NETSTANDARD2_1_OR_GREATER || NET uses [argument], falling back to new object?[]{ argument } otherwise. Behavior and overload shape are preserved.

---

2276-2308: Info(object? argument) V1 overloads follow the same span pattern

The Info V1 overloads with a single object? parameter now delegate to WriteToTargetsWithSpan under NET with [argument], keeping the traditional array-based path for other TFMs. The change is consistent with the rest of the file.

---

2475-2509: Warn V1 overloads (2–3 args) correctly migrated to span routing

Warn overloads with multiple object? arguments now use [arg1, arg2] / [arg1, arg2, arg3] for the NET span path, preserving previous logic and only changing the way arguments are transported.

---

2633-2665: Warn(string? argument) V1 overloads: span path consistent and symmetric

For single string? arguments, Warn now uses WriteToTargetsWithSpan with [argument] under NET and keeps the new object?[]{ argument } fallback. This is symmetrical with Trace/Debug/Info/Error/Fatal.

---

2863-2895: Warn(object? argument) V1 overloads use span-based path as expected

The Warn object-based overloads route via [argument] to WriteToTargetsWithSpan for NET targets and retain the previous array allocation otherwise. No other behavior changes.

---

3062-3096: Error V1 overloads (2–3 args) updated to span routing correctly

Error overloads with 2–3 object? arguments mirror the Warn/Info changes, with [arg1, arg2] / [arg1, arg2, arg3] feeding the span-based path. The structure and guards are unchanged.

---

3220-3252: Error(string? argument) V1 overloads: span-based routing matches other levels

Single-argument Error overloads for string? now use [argument] for NET while keeping the object-array path for other TFMs, aligned with Trace/Debug/Info/Warn/Fatal.

---

3450-3482: Error(object? argument) V1 overloads: span callsites wired correctly

The Error overloads that take an object? argument are updated to use WriteToTargetsWithSpan(LogLevel.Error, ..., [argument]) under NET, with unchanged behavior otherwise. Argument order and culture parameters look correct.

---

3649-3683: Fatal V1 overloads (2–3 args) correctly switch to span-based routing

Fatal multi-argument overloads now feed [arg1, arg2] / [arg1, arg2, arg3] into WriteToTargetsWithSpan in the NET span path. The prior object-array behavior is preserved in the #else branch.

---

3807-3839: Fatal(string? argument) V1 overloads: span packaging consistent

The Fatal overloads with a single string? argument now use [argument] under NETSTANDARD2_1_OR_GREATER || NET, matching the pattern used across other log levels, with no observable behavior change.

---

4037-4069: Fatal(object? argument) V1 overloads: span-based path matches Error/Warn

Single object? argument Fatal overloads now call WriteToTargetsWithSpan(LogLevel.Fatal, ..., [argument]) under NET, and fall back to the legacy array-based call otherwise. This keeps the V1 compat surface aligned with the main Logger.

tests/NLog.RegEx.Tests/ColoredConsoleTargetTests.cs (1)

167-172: Broadened span-based Write override matches runtime capabilities

The PartsWriter.Write(ReadOnlySpan<char> buffer) override is now enabled under NETSTANDARD2_1_OR_GREATER || NET, which aligns with where TextWriter.Write(ReadOnlySpan<char>) exists. The body still just captures the buffer as a string, so behavior is unchanged; only test coverage across TFMs is improved.

tests/NLog.UnitTests/LogMessageFormatterTests.cs (1)

103-109: LGTM! Conditional compilation aligned with production code.

The broadened #if NETSTANDARD2_1_OR_GREATER || NET condition correctly enables Span-based test paths for all modern .NET targets. The use of explicit Span<T> constructor (not collection expressions) is compatible with all NET versions.

Also applies to: 135-140

src/NLog/Logger.cs (1)

606-668: Well-structured span-based logging implementation.

The WriteToTargetsWithSpan methods correctly use in ReadOnlySpan<object?> to avoid unnecessary copies. The implementation appropriately:

• Handles empty spans with args.IsEmpty ? null : args.ToArray()
• Provides optimized pre-formatting path for message templates
• Falls back to string.Format when positional templates are detected
• Includes proper exception handling with InternalLogger fallback

Reviewing files that changed from the base of the PR and between ae86481 and 7f08e88.

• src/NLog/Common/AsyncLogEventInfo.cs
• src/NLog/Common/InternalLogger.cs
• src/NLog/Conditions/ConditionExpression.cs
• src/NLog/Conditions/ConditionLiteralExpression.cs
• src/NLog/Conditions/ConditionMethods.cs
• src/NLog/Conditions/ConditionRelationalExpression.cs
• src/NLog/Config/AssemblyExtensionLoader.cs
• src/NLog/Config/LoggerNameMatcher.cs
• src/NLog/Config/LoggingConfiguration.cs
• src/NLog/Config/MethodFactory.cs
• src/NLog/Config/PropertyTypeConverter.cs
• src/NLog/Filters/WhenRepeatedFilter.cs
• src/NLog/Internal/AppEnvironmentWrapper.cs
• src/NLog/Internal/AssemblyHelpers.cs
• src/NLog/Internal/CallSiteInformation.cs
• src/NLog/Internal/DictionaryEntryEnumerable.cs
• src/NLog/Internal/ExceptionMessageFormatProvider.cs
• src/NLog/Internal/FormatHelper.cs
• src/NLog/Internal/LogMessageTemplateFormatter.cs
• src/NLog/Internal/MultiFileWatcher.cs
• src/NLog/Internal/ObjectGraphScanner.cs
• src/NLog/Internal/ObjectReflectionCache.cs
• src/NLog/Internal/PropertiesDictionary.cs
• src/NLog/Internal/PropertyHelper.cs
• src/NLog/Internal/ReflectionHelpers.cs
• src/NLog/Internal/ScopeContextAsyncState.cs
• src/NLog/Internal/SingleItemOptimizedHashSet.cs
• src/NLog/Internal/StackTraceUsageUtils.cs
• src/NLog/Internal/StringBuilderExt.cs
• src/NLog/Internal/TargetWithFilterChain.cs
• src/NLog/Internal/TimeoutContinuation.cs
• src/NLog/Internal/XmlHelper.cs
• src/NLog/LayoutRenderers/AssemblyVersionLayoutRenderer.cs
• src/NLog/LayoutRenderers/BaseDirLayoutRenderer.cs
• src/NLog/LayoutRenderers/NLogDirLayoutRenderer.cs
• src/NLog/LayoutRenderers/ProcessDirLayoutRenderer.cs
• src/NLog/LayoutRenderers/ProcessInfoLayoutRenderer.cs
• src/NLog/LayoutRenderers/StackTraceLayoutRenderer.cs
• src/NLog/LayoutRenderers/ThreadNameLayoutRenderer.cs
• src/NLog/LayoutRenderers/Wrappers/WrapLineLayoutRendererWrapper.cs
• src/NLog/Layouts/SimpleLayout.cs
• src/NLog/Layouts/Typed/Layout.cs
• src/NLog/Layouts/Typed/ValueTypeLayoutInfo.cs
• src/NLog/LogEventBuilder.cs
• src/NLog/LogEventInfo.cs
• src/NLog/LogFactory.cs
• src/NLog/LogLevelTypeConverter.cs
• src/NLog/Logger-V1Compat.cs
• src/NLog/Logger-generated.cs
• src/NLog/Logger-generated.tt
• src/NLog/Logger.cs
• src/NLog/MessageTemplates/ValueFormatter.cs
• src/NLog/ScopeContext.cs
• src/NLog/Targets/AsyncTaskTarget.cs
• src/NLog/Targets/ColoredConsoleAnsiPrinter.cs
• src/NLog/Targets/ColoredConsoleSystemPrinter.cs
• src/NLog/Targets/DefaultJsonSerializer.cs
• src/NLog/Targets/FileArchiveHandlers/BaseFileArchiveHandler.cs
• src/NLog/Targets/FileArchiveHandlers/LegacyArchiveFileNameHandler.cs
• src/NLog/Targets/FileTarget.cs
• src/NLog/Targets/LineEndingMode.cs
• src/NLog/Targets/MethodCallTarget.cs
• src/NLog/Targets/TargetWithContext.cs
• src/NLog/Targets/Wrappers/AsyncTargetWrapper.cs
• src/NLog/Targets/Wrappers/BufferingTargetWrapper.cs
• tests/NLog.RegEx.Tests/ColoredConsoleTargetTests.cs
• tests/NLog.UnitTests/LogMessageFormatterTests.cs
• tests/NLog.UnitTests/Targets/ColoredConsoleTargetTests.cs

• src/NLog/Targets/FileArchiveHandlers/LegacyArchiveFileNameHandler.cs
• src/NLog/Conditions/ConditionMethods.cs
• src/NLog/LayoutRenderers/BaseDirLayoutRenderer.cs
• src/NLog/Filters/WhenRepeatedFilter.cs
• src/NLog/Internal/MultiFileWatcher.cs
• src/NLog/Targets/FileArchiveHandlers/BaseFileArchiveHandler.cs
• src/NLog/Targets/DefaultJsonSerializer.cs
• src/NLog/Config/AssemblyExtensionLoader.cs
• src/NLog/Internal/XmlHelper.cs
• src/NLog/Internal/FormatHelper.cs
• src/NLog/Internal/ObjectReflectionCache.cs
• src/NLog/Targets/AsyncTaskTarget.cs
• src/NLog/Targets/Wrappers/AsyncTargetWrapper.cs
• src/NLog/LogEventBuilder.cs
• src/NLog/Config/MethodFactory.cs
• src/NLog/Internal/ObjectGraphScanner.cs
• src/NLog/Targets/TargetWithContext.cs
• src/NLog/LayoutRenderers/ProcessInfoLayoutRenderer.cs
• src/NLog/LayoutRenderers/ProcessDirLayoutRenderer.cs
• src/NLog/Targets/FileTarget.cs
• src/NLog/Layouts/SimpleLayout.cs
• src/NLog/LayoutRenderers/Wrappers/WrapLineLayoutRendererWrapper.cs
• tests/NLog.UnitTests/Targets/ColoredConsoleTargetTests.cs
• src/NLog/LayoutRenderers/StackTraceLayoutRenderer.cs
• src/NLog/Layouts/Typed/ValueTypeLayoutInfo.cs
• src/NLog/ScopeContext.cs
• src/NLog/Config/LoggerNameMatcher.cs
• src/NLog/Targets/ColoredConsoleAnsiPrinter.cs
• src/NLog/Conditions/ConditionExpression.cs
• src/NLog/Internal/DictionaryEntryEnumerable.cs
• src/NLog/Targets/ColoredConsoleSystemPrinter.cs
• src/NLog/Common/InternalLogger.cs
• src/NLog/Config/LoggingConfiguration.cs
• src/NLog/LogEventInfo.cs
• tests/NLog.RegEx.Tests/ColoredConsoleTargetTests.cs
• src/NLog/Internal/AppEnvironmentWrapper.cs
• src/NLog/Internal/AssemblyHelpers.cs
• src/NLog/Internal/ExceptionMessageFormatProvider.cs
• src/NLog/Common/AsyncLogEventInfo.cs
• src/NLog/Layouts/Typed/Layout.cs
• src/NLog/Conditions/ConditionRelationalExpression.cs

• GitHub Check: task-list-completed

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

376-379: LGTM! Nullable annotation correctly applied.

The nullable annotation on the Equals method parameter aligns with .NET nullable reference type best practices. The implementation correctly handles null through pattern matching, which returns false when obj is null.

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

96-96: LGTM! Correct nullable annotation for Timer callback.

The parameter type change aligns with the TimerCallback delegate signature, which expects object? state. Since null is passed as the state argument on line 57 and the parameter is unused in the method body, this is a safe and appropriate nullable annotation.

src/NLog/LayoutRenderers/AssemblyVersionLayoutRenderer.cs (1)

178-178: LGTM! Nullable annotation correctly reflects GetEntryAssembly() behavior.

The change accurately annotates that Assembly.GetEntryAssembly() can return null in certain hosting scenarios. The existing code at lines 157, 160, and 163 already handles this case correctly using null-conditional operators.

src/NLog/Targets/Wrappers/BufferingTargetWrapper.cs (1)

274-313: LGTM! Nullable annotation correctly applied.

The nullable annotation on the state parameter correctly aligns with .NET's Timer callback signature. The existing null-safe handling using (state as int?) ?? 0 on line 280 ensures no behavioral change.

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

750-758: LGTM! Nullable annotation correctly added to Equals override.

The signature now properly declares that obj can be null, aligning with .NET's nullable reference types and the standard object.Equals(object?) signature. The method body already handles null safely by returning false when the object doesn't match the expected types.

src/NLog/Conditions/ConditionLiteralExpression.cs (1)

81-81: LGTM! Defensive null-coalescing for .NET 10 nullability compliance.

The addition of ?? string.Empty correctly addresses the .NET 10 nullable annotation warnings for Convert.ToString() while ensuring ToString() always returns a non-null string as per its signature. Since LiteralValue is already verified as non-null at this point (line 66), this is purely defensive programming to satisfy the compiler's nullability analysis.

src/NLog/Config/PropertyTypeConverter.cs (1)

199-208: LGTM! Explicit null check improves nullable reference type analysis.

The explicit stringValue is null check on Line 201 aligns with the PR objective of addressing .NET 10 nullable warnings. While StringHelpers.IsNullOrWhiteSpace already handles null values correctly, the explicit check makes the null-handling intent clearer and helps the nullable reference type analyzer.

src/NLog/Targets/MethodCallTarget.cs (1)

270-272: LGTM! Null-check correctly handles nullable InnerException.

The null-check properly addresses the .NET 10 nullable annotation for TargetInvocationException.InnerException. The fallback to throw; ensures the original exception is rethrown with its stack trace intact when InnerException is null.

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

586-592: LGTM! Consistent null-safety pattern.

The addition of ?? GetType().ToString() aligns with the defensive null-handling pattern used consistently throughout the codebase for ToString() overrides (e.g., ScopeContext.ScopeContextPropertiesCollapsed.ToString(), TargetWithContext, and multiple Layout classes). This appropriately addresses .NET 10 nullable annotations.

src/NLog/MessageTemplates/ValueFormatter.cs (2)

266-272: LGTM! Nullability annotation aligns with .NET 10.

The parameter change from string to string? correctly addresses .NET 10 nullable annotations. StringBuilder.Append(string?) safely handles null values, and the change accommodates call sites like Line 203 where IConvertible.ToString() may return null in .NET 10.

---

355-363: LGTM! Nullability annotation correctly reflects collection semantics.

The parameter change from object to object? appropriately handles nullable collection items. The method implementation safely handles null through pattern matching (lines 357, 359) and delegates to methods that accept nullable values (SerializeSimpleObject checks for null at Line 189, Convert.ToString handles null).

src/NLog/Targets/LineEndingMode.cs (3)

188-191: LGTM! Correct nullable annotation for Object.Equals override.

The nullable parameter annotation aligns with standard C# patterns for Object.Equals, and the implementation correctly handles null input through pattern matching.

---

196-199: LGTM! Correct nullable annotation for IEquatable implementation.

The nullable parameter annotation follows the standard IEquatable<T> pattern, and the implementation correctly returns false for null input using the null-conditional operator.

---

213-217: LGTM! Correct nullable return type for TypeConverter override.

The nullable return type correctly reflects that base.ConvertFrom can return null, improving type safety for consumers of this converter.

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

242-245: LGTM! Nullable parameter annotations correctly align with .NET interface.

The updated signature correctly reflects the nullable reference type annotations in .NET's IEqualityComparer<T>.Equals interface. The implementation using ReferenceEquals handles null values correctly.

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

107-107: LGTM: Good null-safety improvement.

The null-coalescing operator appropriately guards against a potential null return from method.ToString(), which may be annotated as nullable in .NET 10. The fallback to methodName preserves the original behavior.

src/NLog/LogLevelTypeConverter.cs (2)

46-49: LGTM - Nullable context annotation is correct.

The nullable context parameter aligns with the .NET 10 TypeConverter base class signature.

---

64-67: LGTM - Nullable annotations are correct.

The nullable context and destinationType parameters align with the .NET 10 TypeConverter base class signature.

src/NLog/Internal/CallSiteInformation.cs (2)

310-321: LGTM! Excellent null-safety improvements.

The refactoring effectively addresses nullable reference type warnings:

• Early null check (line 310) prevents passing null to LookupAssemblyFromMethod, which expects a non-nullable MethodBase
• Extracting declaringType to a local variable (line 317) improves readability and ensures proper null checking before calling IsHiddenClassType
• Explicit return false (line 321) clarifies the control flow

These changes align well with the PR's objective to fix nullable warnings from .NET 10 annotations.

---

329-329: LGTM! Minor style improvement.

Using var for the local variable declaration improves consistency with modern C# conventions.

src/NLog/LayoutRenderers/NLogDirLayoutRenderer.cs (1)

93-93: LGTM: Null-safety improvement.

The null-coalescing operator correctly ensures ResolveNLogDir always returns a non-null string, as Path.GetDirectoryName can return null per the .NET API.

src/NLog/Internal/ReflectionHelpers.cs (3)

183-186: LGTM: Correct nullable parameter annotation.

Making the PropertyInfo parameter nullable accurately reflects the method's implementation, which already handles null via the p != null check. This aligns with the usage in ObjectReflectionCache.cs where the method is called within LINQ expressions on potentially null PropertyInfo instances.

---

188-195: LGTM: Accurate nullable return type.

Changing the return type to object? correctly reflects that property values can be null. The parameter p remaining non-nullable is also appropriate since a valid PropertyInfo instance is required to retrieve a value.

---

74-74: The preprocessor directive change aligns with the codebase's standard pattern. The actual code uses #if NETSTANDARD2_1_OR_GREATER || NET, which is the established pattern used consistently across 40+ locations in the codebase (LogEventInfo.cs, Logger-generated.cs, SimpleLayout.cs, and others). The runtime check for IsDynamicCodeSupported is present and handles multi-targeting correctly. No concerns with this change.

src/NLog/LayoutRenderers/ThreadNameLayoutRenderer.cs (1)

55-58: LGTM! Correct nullable annotation for Thread.Name.

The nullable return type properly reflects that Thread.CurrentThread.Name can be null. The existing usage at line 52 with StringBuilder.Append() is safe since it handles null values by treating them as empty strings.

tests/NLog.UnitTests/LogMessageFormatterTests.cs (1)

103-103: LGTM: Test coverage broadened to all NET targets.

The preprocessor condition change from NETCOREAPP3_1_OR_GREATER to NET correctly aligns test coverage with the implementation changes, enabling span-based LogEventInfo3 testing on all NET targets.

Also applies to: 135-135

src/NLog/Logger.cs (2)

606-607: LGTM: Correct use of 'in' modifier with ReadOnlySpan.

The method signature changes from params ReadOnlySpan<object?> to in ReadOnlySpan<object?> are correct. The in modifier ensures the ReadOnlySpan is passed by reference without defensive copies, which is the recommended pattern for ReadOnlySpan parameters.

Also applies to: 616-616

---

644-667: LGTM: Preformatted log event rendering implementation.

The RenderPreformattedLogEvent method correctly uses the in modifier with ReadOnlySpan and includes proper error handling for template formatting failures.

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

101-106: Span-based logging optimization looks good

The changes consistently route logging calls to WriteToTargetsWithSpan with collection expression syntax [arg1, arg2] for NETSTANDARD2_1_OR_GREATER || NET targets, while maintaining backward compatibility with object[] arrays for older targets. This aligns with the PR's objective to leverage modern runtime features and reduce allocations.

Also applies to: 127-132, 268-273, 511-516, 718-723, 1106-1111

src/NLog/LogFactory.cs (5)

288-296: LGTM: Event handler sender parameter correctly annotated as nullable.

The nullable annotation on the sender parameter is appropriate for event handlers and consistent with the other event handler signatures in this file (lines 1227, 1249).

---

1113-1116: LGTM: Standard nullable override for Equals method.

The nullable annotation on the obj parameter correctly matches the modern signature of Object.Equals and is consistent with similar patterns in other files (LogLevel.cs, LineEndingMode.cs, etc.).

---

1227-1247: LGTM: Event handler correctly annotated with nullable sender.

The nullable annotation is appropriate for this event handler. Note that line 1231 explicitly passes null as the sender when invoking _loggerShutdown, confirming that null is an expected value.

---

1249-1274: LGTM: Event handler correctly annotated with nullable sender.

The nullable annotation is appropriate and consistent with the other event handler signatures in this file.

---

54-56: Conditional compilation directive correctly gates IAsyncDisposable to supported frameworks.

The change from NETCOREAPP3_1_OR_GREATER to NETSTANDARD2_1_OR_GREATER || NET is correct. IAsyncDisposable is only available in .NET Standard 2.1+ and .NET Core 3.1+, so the new directive properly excludes the older frameworks in the project's target list (net35, net46, netstandard2.0) where it is unavailable.

src/NLog/Internal/PropertyHelper.cs (2)

439-439: Good defensive null-check for nullable reference type analysis.

While IsValidPublicProperty() already handles null internally, the explicit check helps .NET 10's nullable reference type analysis and makes the intent clearer.

---

175-184: The Try* pattern implementation is correct and consistent across all callers.

The method correctly returns true when a property is found and false when not found, following standard .NET Try* conventions. All callers throughout the codebase (LayoutParser.cs and LoggingConfigurationParser.cs) properly handle this return value, treating true as success and false as failure. The public overload at line 150 correctly delegates to the private method at line 158 and returns its result unchanged.

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

424-432: This review comment is based on an incorrect premise and should be disregarded.

The file src/NLog/Internal/StringBuilderExt.cs is being created as a new file in this commit, not modified. There was no previous preprocessor condition to change from NETCOREAPP3_0_OR_GREATER to NET.

The condition #if NETSTANDARD2_1_OR_GREATER || NET is appropriate for the project's actual target frameworks (net35, net46, netstandard2.0, netstandard2.1):

• netstandard2.1 has LangVersion=13, which fully supports C# 12 collection expressions
• The NET macro correctly covers .NET 5.0+ unified framework
• The project never targeted netcoreapp3.0 or netcoreapp3.1, so there is no excluded framework to fall back to the multiple-Append path

Likely an incorrect or invalid review comment.