-
Notifications
You must be signed in to change notification settings - Fork 10.2k
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
Fix all -Wdeprecated warnings; eliminate GTEST_DISALLOW_ASSIGN_ #2815
Conversation
…me performance. We are about to remove all uses of GTEST_DISALLOW_ASSIGN_ in favor of using the Rule of Zero everywhere. Unfortunately, if we use the Rule of Zero here, then when the compiler needs to figure out if VariadicMatcher is move-constructible, it will recurse down into `tuple<Args...>`, which on libstdc++ recurses too deeply. In file included from googlemock/test/gmock-matchers_test.cc:43: In file included from googlemock/include/gmock/gmock-matchers.h:258: In file included from /usr/include/c++/5.5.0/algorithm:60: In file included from /usr/include/c++/5.5.0/utility:70: In file included from /usr/include/c++/5.5.0/bits/stl_pair.h:59: In file included from /usr/include/c++/5.5.0/bits/move.h:57: /usr/bin/include/c++/5.5.0/type_traits:115:26: fatal error: recursive template instantiation exceeded maximum depth of 256 : public conditional<_B1::value, _B1, _B2>::type ^ The move constructor is the only problematic case, for some unknown reason. With GTEST_DISALLOW_ASSIGN_, the presence of a copy assignment operator causes the move constructor to be non-declared, thus non-defaulted, thus non-problematic. Without GTEST_DISALLOW_ASSIGN_, we have to do one of the following: - Default the copy constructor, so that the move constructor will be non-declared. - Define our own non-defaulted move constructor. ...except that doing the latter STILL did not work! Fortunately, the former (default the copy constructor, don't provide any move constructor) both works in practice and is semantically equivalent to the old code.
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.
Thanks for your efforts! We agree that these types should still be move constructible, however, we think it is better to explicitly spell it out, i.e. Type(Type&&) = default;
, rather than relying on the presence of const
members. Could you please add user-declared move ctors? Thanks again!
@zhangxy988: Sure, I think I'm amenable to Also, for types with |
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.
In general, I am OK with just mechanically replace GTEST_DISALLOW_ASSIGN_
with Type& operator=(const Type&) = delete;
.
Move ctor can be considered separately.
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.
After more thought, I think I agree with your approach here, i.e. rule of zero, I will import this for an internal review.
Though this macro is supposed to be internal, it's unfortunately used inside Google and removing it would cause breakages. I am going to clean them up, but you can choose to wait for my cleanup to complete (which delays this PR) or keep the macro for now. Let me know how you want to proceed. |
None of these are strictly needed for correctness. A large number of them (maybe all of them?) trigger `-Wdeprecated` warnings on Clang trunk as soon as you try to use the implicitly defaulted (but deprecated) copy constructor of a class that has deleted its copy assignment operator. By declaring a deleted copy assignment operator, the old code also caused the move constructor and move assignment operator to be non-declared. This means that the old code never got move semantics -- "move-construction" would simply call the defaulted (but deprecated) copy constructor instead. With the new code, "move-construction" calls the defaulted move constructor, which I believe is what we want to happen. So this is a runtime performance optimization. Unfortunately we can't yet physically remove the definitions of these macros from gtest-port.h, because they are being used by other code internally at Google (according to zhangxy988). But no new uses should be added going forward.
gmock-spec-builders.h:503:3: error: definition of implicit copy constructor for 'Expectation' is deprecated because it has a user-declared destructor [-Werror,-Wdeprecated] ~Expectation(); ^
googletest-port-test.cc:97:11: error: definition of implicit copy constructor for 'Base' is deprecated because it has a user-declared destructor [-Werror,-Wdeprecated] virtual ~Base() {} ^
googletest-param-test-test.cc:502:8: error: definition of implicit copy constructor for 'NonDefaultConstructAssignString' is deprecated because it has a user-declared copy assignment operator [-Werror,-Wdeprecated] void operator=(const NonDefaultConstructAssignString&); ^
@zhangxy988 wrote:
No problem. I've modified the first commit in this PR so that it no longer removes the macro definitions. |
The ACTION_P generated code introduces -Wdeprecated warning as it provides its own assignment operator implementation but no copy assignment constructor. The issue seem to be fixed in google/googletest#2815 but this is not yet included into latest gtest release.
They were all removed in google#2815, but it looks like this one got added from a Google export which missed the update. See google#2815 for reasons why removing this is desirable.
See google/googletest#2815 for the reasons why this is desirable. Some things are in different places, but most of the same lines exist, so apply the same change to them. Change-Id: I054d2cd00aec96c9e1562f35eeda05cb89ed049e Signed-off-by: Brian Silverman <[email protected]>
Cherry-pick google/googletest#2815 to fix the -Wdeprecated-copy warnings of recent versions of Clang (13 or later). The patch was suggested by Mark Wachsler. Change-Id: I0cc88543e7bc68af6292ddc3773dad38c459cc72
Update the pinned revision for googletest to pick up google/googletest#2815 which should allow us to repair the macOS builds.
Update the pinned revision for googletest to pick up google/googletest#2815 which should allow us to repair the macOS builds. Add a workaround for dependency tracking to try to avoid a build race.
Update the pinned revision for googletest to pick up google/googletest#2815 which should allow us to repair the macOS builds. Add dependency tracking to try to avoid a build race with capstone and libbloaty.
Update the pinned revision for googletest to pick up google/googletest#2815 which should allow us to repair the macOS builds. Add dependency tracking to try to avoid a build race with capstone and libbloaty.
Update the pinned revision for googletest to pick up google/googletest#2815 which should allow us to repair the macOS builds. Add dependency tracking to try to avoid a build race with capstone and libbloaty.
Cherry-pick google/googletest#2815 to fix the -Wdeprecated-copy warnings of recent versions of Clang (13 or later). The patch was suggested by Mark Wachsler. Change-Id: I0cc88543e7bc68af6292ddc3773dad38c459cc72
Cherry-pick google/googletest#2815 to fix the -Wdeprecated-copy warnings of recent versions of Clang (13 or later). The patch was suggested by Mark Wachsler. Change-Id: I0cc88543e7bc68af6292ddc3773dad38c459cc72
This is the spiritual successor to #2774 (which I tried and failed to reopen) and #2758.
Fixes #1305.
Remove all uses of
GTEST_DISALLOW_{MOVE_,}ASSIGN_
.Add
-Wdeprecated
to the build configuration.The change in
VariadicMatcher
looks deceptively simple, but I actually still don't really understand what's going on with it; feel free to dig deeper if you can.@mbxx @zhangxy988 please take a look!