Only generate dynamic calls when class has generic params#1388
Merged
davidmorgan merged 1 commit intogoogle:masterfrom Feb 20, 2026
Merged
Only generate dynamic calls when class has generic params#1388davidmorgan merged 1 commit intogoogle:masterfrom
davidmorgan merged 1 commit intogoogle:masterfrom
Conversation
Currently, a dynamic call is generated when a field is a function (previously added [back in 2018](google#498)). Without the dynamic call, [this test](https://github.com/google/built_value.dart/blob/f20857b873aa6c77395b75aa18a4c03b80f18017/end_to_end_test/test/generics_test.dart#L71-L81) fails. The error message is: ``` 00:00 +9 -1: GenericFunction can be compared [E] │ type '(int) => Null' is not a subtype of type '(dynamic) => dynamic' │ package:end_to_end_test/generics.g.dart 1726:58 _$GenericFunction.== │ test/generics_test.dart 77:63 main.<fn>.<fn> ``` In this commit, only use dynamic calls when the enclosing class has generic parameters. This should eliminate a significant number of dynamic call generation in cases that don't need it. Ideally we would only generate the dynamic call when the *field* is a function and uses type parameters from the enclosing class, but my understanding is that is much more complex and requires deeper integration with the analyzer. The *.g.dart files were regenerated by locally modifying the pubspec of end_to_end_test to use dependency_overrides to point to the local repo (not sure if this is the right approach). Motivation: Dynamic modules do not support dynamic calls and the current generation of dynamic calls makes using built_value in dynamic modules problematic. See b/481568738 for details. Tested: Running the tests, and also doing an internal global presubmit with this change.
Member
Author
|
@davidmorgan would you be able to take a look if this is right :) |
Collaborator
|
Thanks! I asked about the cast problem with functions, it's possible to make it work for functions by generating a getter/method that avoids doing the cast but we would still have the problem of detecting when to do this, as you observed. Since nobody is actually asking for functions in generic types to work I think this workaround is fine. Normally I would insist on putting a test of the new functionality in end_to_end_tests, but I don't see a way to check that no dynamic call happens, so the unit test looks fine. LGTM, thanks! I'll merge + roll into google3. |
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.
Currently, a dynamic call is generated when a field is a function (previously added back in 2018). Without the dynamic call, this test fails. The error message is:
In this commit, only use dynamic calls when the enclosing class has generic parameters. This should eliminate a significant number of dynamic call generation in cases that don't need it.
Ideally we would only generate the dynamic call when the field is a function and uses type parameters from the enclosing class, but my understanding is that is much more complex and requires deeper integration with the analyzer.
The *.g.dart files were regenerated by locally modifying the pubspec of end_to_end_test to use dependency_overrides to point to the local repo (not sure if this is the right approach).
Motivation: Dynamic modules do not support dynamic calls and the current generation of dynamic calls makes using built_value in dynamic modules problematic. See b/481568738 for details.
Tested: Running the tests, and also doing an internal global presubmit with this change.