Repository navigation
Short-circuit a null-conditional operator after a cast - #22174
Merged
Merged
Conversation
Follow-up to AvaloniaUI#22082, which added the short-circuit to the property accessor nodes. The cast nodes still called ValidateNonNullSource, so a cast reported "Value is null" before the following ?. could suppress it. Casting null now produces null, as in C#, leaving any error to the member access that follows.
|
You can test this PR using the following package version. |
MrJul
added
area-bindings
backport-candidate-12.1.x
grokys
approved these changes
Sep 9, 2026
| /// <summary> | ||
| /// A top-level type used to test casting in a binding path. | ||
| /// </summary> | ||
| public class DerivedSecond : NullConditionalBindingTests.Second |
Member
There was a problem hiding this comment.
Not crazy about having a top-level type derive from a nested type here, but I guess they're only unit tests.
MrJul
pushed a commit
to MrJul/Avalonia
that referenced
this pull request
Sep 22, 2026
) Follow-up to AvaloniaUI#22082, which added the short-circuit to the property accessor nodes. The cast nodes still called ValidateNonNullSource, so a cast reported "Value is null" before the following ?. could suppress it. Casting null now produces null, as in C#, leaving any error to the member access that follows.
MrJul
added
backported-12.1.x
and removed
backport-candidate-12.1.x
grokys
pushed a commit
to Evan260/Avalonia
that referenced
this pull request
Oct 7, 2026
) Follow-up to AvaloniaUI#22082, which added the short-circuit to the property accessor nodes. The cast nodes still called ValidateNonNullSource, so a cast reported "Value is null" before the following ?. could suppress it. Casting null now produces null, as in C#, leaving any error to the member access that follows.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does the pull request do?
Follow-up to #22082. A null-conditional operator after a cast now short-circuits instead of logging an error.
What is the current behavior?
logs:
Without the cast it's fine.
What is the updated/expected behavior with this PR?
No error, same as without the cast.
How was the solution implemented (if it's not obvious)?
#22082 added the short-circuit to the property accessor nodes, but the cast nodes still called
ValidateNonNullSource, so the cast reported the error before the?.could suppress it. There are two of them:ReflectionTypeCastNodefor reflection bindings andFuncTransformNodefor compiled ones, the latter only ever being used for casts.Rather than thread an
acceptsNullflag through the grammar, casting null now just produces null, like it does in C#. Any error then belongs to the member access that follows, which is where?.gets a say. I checked that a path without?.still reports the error.It has to be
SetValue(null)and notClearValue().ClearValuegivesUnsetValue, which the next node still errors on, so nothing short-circuits.Two things for you to weigh
ReflectionTypeCastNodea null source now takesSetValue(null)while a type mismatch still takesClearValue(). That difference was already there, but this change puts the two next to each other.Checklist
One test in
NullConditionalBindingTests, covering compiled and reflection bindings. Both fail on main with the error above.Breaking changes
For a null cast with no
?., the error is now reported at the member access rather than at the cast. Same message, same failure.Fixed issues
Fixes #22136