Copilot commented on code in PR #2747:
URL: https://github.com/apache/groovy/pull/2747#discussion_r3673122086
##########
subprojects/groovy-typecheckers/src/main/groovy/groovy/typecheckers/NullChecker.groovy:
##########
@@ -539,6 +584,31 @@ class NullChecker extends
GroovyTypeCheckingExtensionSupport.TypeCheckingDSL {
false
}
+ /**
+ * A safe-navigation result ({@code a?.b} or {@code a?.b()}) is null
whenever its receiver is.
+ */
+ private static boolean isSafeNavResult(Expression expr) {
+ (expr instanceof PropertyExpression && expr.safe) || (expr instanceof
MethodCallExpression && expr.safe)
+ }
Review Comment:
The docstring is potentially misleading: safe-navigation results are null
when the receiver is null, but they can also be null for other reasons (e.g.,
the accessed property value is null, or the method returns null). Consider
rewording to something like “may be null at least when its receiver is null” to
better match the semantics and avoid future misuse of this helper.
##########
subprojects/groovy-typecheckers/src/spec/doc/typecheckers.adoc:
##########
@@ -721,9 +721,22 @@ patterns also combines with the early-exit form, e.g.
include::../test/NullCheckerTest.groovy[tags=broader_guards,indent=0]
----
-*Ternary and elvis expressions*: in flow-sensitive mode (`NullChecker(strict:
true)`), the checker
-examines both branches of ternary (`condition ? a : b`) and elvis (`x ?:
fallback`) expressions.
-If either branch can be null, the result is treated as nullable. The elvis
assignment
+*Ternary and elvis expressions*: the checker examines the branches of ternary
+(`condition ? a : b`) and elvis (`x ?: fallback`) expressions. A ternary is
treated as
+nullable if either branch can be null, judging each branch under the
condition's own
+guard facts, so `s != null ? s : 'default'` is not considered nullable. An
elvis
+expression is nullable only if its fallback is, since a Groovy-truthy value is
never
+null — making `x ?: 'default'` a recognized way to pass a `@Nullable` value
where a
+non-null value is required:
Review Comment:
These lines appear to have dropped the leading table-cell delimiter (`|`)
that existed previously (e.g. `|*Ternary...`). If this section is inside an
AsciiDoc table (likely, given the prior `|`), removing it will break table
structure/formatting by merging content into the previous cell. Restore the
leading `|` (or adjust the surrounding table markup) so the row/cell boundaries
remain valid.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
