-
Notifications
You must be signed in to change notification settings - Fork 29.7k
add noSuchMethod to _MulticastCanvas to unblock smoke testing against forthcoming new getTransform/Clip methods #103737
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add noSuchMethod to _MulticastCanvas to unblock smoke testing against forthcoming new getTransform/Clip methods #103737
Conversation
|
It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat (don't just cc him here, he won't see it! He's on Discord!). If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix? Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. |
jonahwilliams
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@dnfield to confirm we need these APIs, I lost track of the discussion a bit 😄
|
(landing this would be harmless though, so still LGTM) |
| _screenshot.clipRect(rect, clipOp: clipOp, doAntiAlias: doAntiAlias); | ||
| } | ||
|
|
||
| Rect getCurrentClipBounds() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe add a trivial test that checks these are Rect.zero and Identity?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And then amend the tests when they return actual values?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if that would break the roll, then probably not. i'd say its tested by way of allowing the engine PR to land by unbreaking those tests. You could also implement noSuchMethod
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't think of NSM...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
May want to have an @override on these with an ignore so that the analyzer will ignore it now but accept it when they're actually overriding something.
NSM is fine too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I went the NSM route as it's simpler. We might want to consider leaving it there permanently so that this only becomes a problem when new testing code needs the new implementations (in these screenshot tests).
… against forthcoming new getTransform/Clip methods (flutter/flutter#103737)
… against forthcoming new getTransform/Clip methods (flutter/flutter#103737)
… against forthcoming new getTransform/Clip methods (flutter/flutter#103737)
… against forthcoming new getTransform/Clip methods (flutter/flutter#103737)
… against forthcoming new getTransform/Clip methods (flutter/flutter#103737)
The noSuchMethod override prevents the compiler from complaining while we roll the new methods over from the engine.