Repository navigation
Allow casting to a nested type in a binding path - #22173
Merged
Merged
Conversation
The binding path parser built type names with ParseIdentifier, which doesn't accept '+', so a cast like ((local:Outer+Nested)DataContext) stopped parsing at the '+' and then failed expecting a ')'. Parse type names with a variant that accepts '+'. Ordinary identifiers are unchanged.
|
You can test this PR using the following package version. |
MrJul
added
bug
area-bindings
backport-candidate-12.1.x
grokys
approved these changes
Sep 9, 2026
| { | ||
| if (IsValidIdentifierStart(r.Peek)) | ||
| { | ||
| return r.TakeWhile(c => IsValidIdentifierChar(c) || c == '+'); |
Member
There was a problem hiding this comment.
Note that this will parse types such as Foo+ or Foo++Bar as valid. The types will then fail at the lookup stage so not a huge issue though, doesn't need to be fixed here.
| /// Parses an identifier that may name a nested type, e.g. "Outer+Inner". | ||
| /// </summary> | ||
| public static ReadOnlySpan<char> ParseTypeIdentifier(this | ||
| #if NET7SDK |
Member
There was a problem hiding this comment.
This is vestigial at this point, but it matches other methods in this file, so we can leave it and remove it later.
MrJul
pushed a commit
to MrJul/Avalonia
that referenced
this pull request
Sep 22, 2026
The binding path parser built type names with ParseIdentifier, which doesn't accept '+', so a cast like ((local:Outer+Nested)DataContext) stopped parsing at the '+' and then failed expecting a ')'. Parse type names with a variant that accepts '+'. Ordinary identifiers are unchanged.
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
The binding path parser built type names with ParseIdentifier, which doesn't accept '+', so a cast like ((local:Outer+Nested)DataContext) stopped parsing at the '+' and then failed expecting a ')'. Parse type names with a variant that accepts '+'. Ordinary identifiers are unchanged.
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?
Lets a binding path cast to a nested type, e.g.
{Binding ((local:Outer+Nested)DataContext).SomeProperty}.What is the current behavior?
It fails to compile:
+already works for nested types elsewhere in XAML, for instance inx:DataType='{x:Type local:TestDataContext+NestedGeneric, ...}', which has a test in this repo. It just wasn't accepted in a binding path.What is the updated/expected behavior with this PR?
The cast resolves and the binding works, for both compiled and reflection bindings.
How was the solution implemented (if it's not obvious)?
The binding path parser builds type names with
ParseIdentifier, which doesn't allow+, so parsing stopped at the+and the parser then expected a).Added
ParseTypeIdentifier, which is the same thing but also accepts+, and used it only where a type name is parsed. Ordinary identifiers are unchanged, soFoo+Barin a normal property path is still invalid.Nothing else needed changing. The compiled path passes the name to
TypeReferenceResolver, and the reflection path toAssembly.GetType, and both already understandOuter+Nested.One thing worth flagging
The issue also mentions
.as a separator. I haven't allowed that, because.after a type name is how attached properties are written, as in(ns:Owner.Property), so accepting it there would break them.+is the CLR nested type separator anyway. Happy to revisit if you disagree.Checklist
Four tests: two at the parser level and one each for compiled and reflection bindings. Two of them cover the non-nested case so the existing behaviour stays covered.
Breaking changes
None. This only accepts input that previously failed to compile.
Fixed issues
Fixes #22047