-
Notifications
You must be signed in to change notification settings - Fork 6k
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
Conform to clang_tidy in client_wrapper
headers.
#46058
Merged
matanlurey
merged 2 commits into
flutter:main
from
matanlurey:engine-clientWrapperClangTidy
Sep 19, 2023
Merged
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
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.
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.
Is
BinaryReply
not movable? It looks like it should be:engine/shell/platform/common/client_wrapper/include/flutter/binary_messenger.h
Lines 16 to 17 in 28f14e6
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.
A const reference is not copied, it essentially accomplishes the same thing
(To be clear, this is the result of clang_tidy --fix)
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.
Copying my message from: https://discord.com/channels/608014603317936148/608021010377080866/1153752411614220310
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.
There's more potential argument for supporting copy elision here and sprinkling in some
move
s, but setting handlers isn't a common operation, so absent evidence that we need it we should probably just change to the reference. I don't think I did this intentionally.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.
BinaryReply and BinaryMessageHandler are std::functions.
engine/shell/platform/common/client_wrapper/include/flutter/binary_messenger.h
Lines 13 to 24 in 10c4803
Given that this is code that deals with async responses/message channels, are we introducing any lifetime issues by changing the third param to pass by reference rather than copy?
I'm actually sort of surprised that the compiler isn't shouting about a signature mismatch between the updated usage and definitions above given that it doesn't look like they were updated in this patch.
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.
@stuartmorgan thoughts?
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.
To clarify, here's the scenario I'm thinking of:
BinaryReply
that captures (by reference) one or more of those locals. BinaryReply is astd::function
so it can capture all it likes, unlike a function ptr.BinaryMessageHandler
using thatBinaryReply
which is, as of this change, being passed by reference, and you put that somewhere to be used later.... time passes ...
BinaryReply
and tries to make use of the captured-by-ref local, which is gone now.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.
From a technical standpoint I don't think this changes anything in your scenario. Arguably the by-value signature better communicates that capturing by reference in the function is a bad idea though?
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.
Ah yeah that's a good point. Those captures are going to be equally broken in a by-copy scenario. I suspect the only code that'll be broken by this is code that's already quite racy and unlikely to exist in practice. The BinaryReply itself would need to go out of scope between the time the BinaryMessageHandler is invoked with it and the time it's actually used, which seems pretty unlikely in practice.
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 think we're saying slightly different things. My understanding is that there's no actual lifetime change here; AFAIK the by-value capture of the now-reference argument is still going to make a copy at that point.