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

90-93: Add null-guard for the bool predicate to keep early validation consistent.

Currently a null method would defer failure to evaluation time (NullReferenceException) instead of failing fast like the object-returning overload. Guard it up-front.

Apply this diff:

-        public static ConditionMethodExpression CreateMethodNoParameters(string conditionMethodName, Func<LogEventInfo, bool> method)
-        {
-            return CreateMethodNoParameters(conditionMethodName, (evt) => method(evt) ? BoxedTrue : BoxedFalse);
-        }
+        public static ConditionMethodExpression CreateMethodNoParameters(string conditionMethodName, Func<LogEventInfo, bool> method)
+        {
+            var predicate = Guard.ThrowIfNull(method);
+            return CreateMethodNoParameters(conditionMethodName, evt => predicate(evt) ? BoxedTrue : BoxedFalse);
+        }

---

90-93: Optional: document intent and perf characteristics of the new overload.

A short XML doc helps discoverability and clarifies that it maps to BoxedTrue/BoxedFalse to avoid per-call boxing.

For example (outside the selected lines, above the method):

/// <summary>
/// Convenience overload for parameterless predicates that return bool.
/// Returns cached BoxedTrue/BoxedFalse to avoid per-evaluation boxing.
/// </summary>

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

src/NLog/SetupLoadConfigurationExtensions.cs (1)

677-681: All CreateMethodNoParameters usages already leverage the bool–predicate overload—no further boxing candidates found

I’ve verified across the src folder that:

• Every ConditionMethodExpression.CreateMethodNoParameters(…) invocation accepts a Func<LogEventInfo, bool>, so it already returns the cached BoxedTrue/BoxedFalse.
• There are no direct call sites producing a boxed result that could be switched to the bool overload.
• All remaining ConditionExpression.BoxedTrue/BoxedFalse usages reside within the core condition‐evaluation engine and wrapper filters (e.g. AutoFlushTargetWrapper, PostFilteringTargetWrapper, logical expressions), where they’re used for compare/evaluate logic—not method binding.

No additional manual conversions are required.