fix(generator): correct which call sites the dispatch claims - #91
Merged
Conversation
- A call written as ReactiveUIBindingExtensions.WhenChanged(vm, x => x.Name) puts that class where the observed object goes, so the emitted worker declared a parameter of a static type and took it as a type argument. The consumer's whole build failed on generated code they cannot edit (CS0721, CS0718), every unrelated call site in the project with it. - The shared receiver guard declines a static type alongside a type parameter, which covers every API from one place: each extractor reads the bound object through it. - Nothing could have served those call sites anyway. A call that names the class resolves against that class's members, so neither the generated overload nor an interceptor matching the call written on an instance is a candidate, and the call belongs on the runtime stub.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #91 +/- ##
=======================================
Coverage 99.48% 99.48%
=======================================
Files 250 251 +1
Lines 10651 10652 +1
Branches 1180 1181 +1
=======================================
+ Hits 10596 10597 +1
Misses 42 42
Partials 13 13 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
- Call sites spelling the same selectors were collapsed to one before the interceptors were emitted, so the second one carried no attribute: it took the runtime engine while the call site beside it was generated. Binding the same pair of properties from two places is ordinary, so this bit whole screens of a view at a time. - Collapsing stays where it belongs. Expression-text dispatch keys on the selectors as written, so the later branches are unreachable and only drag a binding method along; an interceptor names the call site it replaces, so nothing may be dropped. - The rule is stated once on the feature snapshot rather than per API. Four emitters decided it separately, and the one that forgot lost a binding without failing to compile. - The tests emit the assembly, because that is where the compiler checks an interceptor against the call it replaces.
|
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 kind of change does this PR introduce?
Bug fix. Two defects in which call sites a dispatch claims.
What is the new behavior?
Every call site an interception build can name is claimed.
A binding call written through the stub's declaring class compiles.
ReactiveUIBindingExtensions.WhenChanged(vm, x => x.Name)and the same shape on every other binding API generate no dispatch, and the call takes the runtime engine like any other shape the generator cannot serve.What is the current behavior?
A repeated call site silently loses its generated binding. Under interception the group is collapsed before the attributes are emitted, so the second call site is left on the runtime expression engine while the one beside it is generated - a whole screen of a view at a time, with the build green.
A call naming the class fails the consumer's whole build. The class itself is read as the observed object, so the emitted worker declares a parameter of a static type and takes it as a type argument:
CS0721andCS0718on generated code the consumer cannot edit, which fails every unrelated call site in the project with it.What might this PR break?
None.
Checklist
mainbranchAdditional information
One test per extractor pins the declined shape, so an API whose argument reading shifts by one is caught where it would otherwise emit uncompilable code. The interception tests emit the assembly, because that is where the compiler checks an interceptor against the call it replaces.