It's not possible to enable it for the rtc_base_approved
target but since a larger refactoring is ongoing for webrtc/base
this CL doesn't attempt to fix that.
Changes made:
* Move webrtc/system_wrappers/include/stringize_macros.h into
webrtc/base:rtc_base_approved_unittests (and corresponding
unit test to rtc_base_approved_unittests).
* Move md5digest.* from rtc_base_approved to rtc_base_test_utils target.
* Move webrtc/system_wrappers/include/stringize_macros.h (+test) into
webrtc/base.
* Remove unused use include of webrtc/base/fileutils.h in
webrtc/base/pathutils.cc
BUG=webrtc:6828, webrtc:3806, webrtc:7480
NOTRY=True
Review-Url: https://codereview.webrtc.org/2717083002
Cr-Commit-Position: refs/heads/master@{#17766}
When implementing ISOLATED_OUTDIR feature in WebRTC, I found two issues,
1. pathutils and flags are not accessible in testsupport. But both of them are
useful for the feature. Pathname can help to combine path with filename, while
a flag is needed to handle command line parameter.
2. rtc::File cannot accept an rtc::Pathname, which is a little bit inconvenient.
After investigating bug webrtc:3806, flags, pathutils and urlencode are
removed from rtc_base_approved because of the including of common.h. So I
replaced common.h with checks.h, and ASSERT with RTC_DCHECK. flags,
pathutils and urlencode pairs now can be placed into rtc_base_approved to
unblock file.h to include pathutils.h.
Please kindly let me know if you have other concerns about this change.
BUG=webrtc:3806, webrtc:6732
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.chromium.mac:mac_chromium_rel_ng;master.tryserver.chromium.win:win_chromium_rel_ng;master.tryserver.chromium.android:linux_android_rel_ng
Review-Url: https://codereview.webrtc.org/2533213005
Cr-Commit-Position: refs/heads/master@{#15451}
They can all benefit from moving, since they contain std::string and
std::vector. We intended to add these in
https://codereview.webrtc.org/1896953004/, but got compiler errors we
couldn't make sense of, so we skipped them. It turns out that what the
compiler was complaining about was that when we said we'd have a
user-defined move constructor, it stopped generating a copy assignment
operator for us. This CL solves the problem by outfitting the types
with defaulted copy and move assignment operators too.
Review URL: https://codereview.webrtc.org/1899173002
Cr-Commit-Position: refs/heads/master@{#12469}
