-
Notifications
You must be signed in to change notification settings - Fork 6k
Use references for C++ MethodResult and EventSink #20651
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2,11 +2,10 @@ | |
| // Use of this source code is governed by a BSD-style license that can be | ||
| // found in the LICENSE file. | ||
|
|
||
| #include "flutter/shell/platform/common/cpp/client_wrapper/include/flutter/method_result_functions.h" | ||
|
|
||
| #include <functional> | ||
| #include <string> | ||
|
|
||
| #include "flutter/shell/platform/common/cpp/client_wrapper/include/flutter/method_result_functions.h" | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I thought that the header corresponding to the cc file always came first... Am I just wrong? Is it supposed to come after the system headers like this? Or is that only in the non-test files?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It should; the style guide is explicit about this. But for reasons that aren't clear to me, clang-format in the engine repo keeps moving the header down in test files. I keep meaning to look into it, then forgetting. I'll file a bug. Maybe it only understands |
||
| #include "gtest/gtest.h" | ||
|
|
||
| namespace flutter { | ||
|
|
@@ -29,7 +28,7 @@ TEST(MethodChannelTest, Success) { | |
| EXPECT_EQ(*i, value); | ||
| }, | ||
| nullptr, nullptr); | ||
| result.Success(&value); | ||
| result.Success(value); | ||
| EXPECT_TRUE(called); | ||
| } | ||
|
|
||
|
|
@@ -50,7 +49,7 @@ TEST(MethodChannelTest, Error) { | |
| EXPECT_EQ(*details, error_details); | ||
| }, | ||
| nullptr); | ||
| result.Error(error_code, error_message, &error_details); | ||
| result.Error(error_code, error_message, error_details); | ||
| EXPECT_TRUE(called); | ||
| } | ||
|
|
||
|
|
||
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.
Do we do the C++14 deprecated annotation thing? Probably not, since warnings-are-errors, but it seems useful.
i.e.:
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.
Exactly. I tried that the last time I did one of these and realized it would just make it an immediate breaking change, which is unfortunate.
In practice, since Windows is still subject to change without warning, it's not a big deal (I'm doing it in stages so I can not break FDE and google3 without having a chance to pre-fix them), but long term it would be nice if we could use them to do soft breaking changes. It's a potential argument for relaxing the template to not treat warnings as errors.