Patch 6/x:
* std::tuple_size<>
* Multiline replacements :)
std::tuple_size<> in base/test/test_future_internal.h has to stay as is
because tuple_size<>::value within enable_if_t should be a part of the
immediate context (while tuple_size_v is not and hence fails with non-
tuple types).
Change-Id: If9e21faaad4fdc241afa272f0eb98dd854608ee3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4954858
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Andrew Rayskiy <greengrape@google.com>
Cr-Commit-Position: refs/heads/main@{#1212334}
MakeIndexSequenceForTuple is a leftover of C++14 adoption around
std::integer_sequence, and tuple.h looks not a good place for it.
This CL just inlines it to caller, and removes MakeIndexSequenceForTuple.
Change-Id: Id397d8ac83ed17310a72abfd31c378f280cd7ad1
Reviewed-on: https://chromium-review.googlesource.com/700157
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Commit-Queue: Taiju Tsuiki <tzik@chromium.org>
Cr-Commit-Position: refs/heads/master@{#507244}
The helper base::MakeIndexSequenceForTuple doesn't have a drop-in replacement
in the STL (std::index_sequence_for takes a parameter pack), so it has been
kept.
Bug: 554717
Change-Id: Ib38ea21855cd5c0f913727282a3603dc05287000
Tbr: jam@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/616082
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Jeremy Roman <jbroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#494802}
base::get is no longer needed after the linux sysroot update. The new
sysroot has libstdc++-4.8, that has rvalue reference support of
std::tuple.
Review-Url: https://codereview.chromium.org/2797133002
Cr-Commit-Position: refs/heads/master@{#462229}
Reverts crrev.com/803183004, maybe the problem
was fixed in 2015. (If not, we can revert the revert again.)
BUG=427616
Review-Url: https://codereview.chromium.org/2576523002
Cr-Commit-Position: refs/heads/master@{#438270}
std::get in libstdc++4.6 doesn't have a overload for rvalue-reference
tuple. That implies std::get<0>(std::make_tuple(1)) is `const int&`,
instead of `int&&`.
This CL add base::get with correct type.
Review-Url: https://codereview.chromium.org/2047013002
Cr-Commit-Position: refs/heads/master@{#401758}
base::Tuple has been an alias of std::tuple for the migration. And this
CL completes the migration by:
- Replace base::Tuple with std::tuple,
- Replace base::MakeTuple with std::make_tuple,
- Replace base::get with std::get,
- Remove base::Tuple, base::MakeTuple, base::get and base::MakeRefTuple
BUG=554987
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation
Review-Url: https://codereview.chromium.org/2023243002
Cr-Commit-Position: refs/heads/master@{#397652}
The only remaining use of these were base::TupleTypes<T>::ValueTuple,
which just maps Tuple<Ts...> to Tuple<remove_reference_t<Ts>...>.
However, all of the uses were for reference-free tuples, making it a
noop.
BUG=554987
Review URL: https://codereview.chromium.org/1768153002
Cr-Commit-Position: refs/heads/master@{#379667}
Remove UnwrapTraits::ForwardType, which is no longer used, and extract
UnwrapTraits::Unwrap to be non member function.
BUG=554299
Review URL: https://codereview.chromium.org/1698223002
Cr-Commit-Position: refs/heads/master@{#375576}
* Make base::DispatchToMethod to accept smart pointers as the this pointer
* Remove base::internal::UnwrapTraits from //storage code
BUG=554299
Review URL: https://codereview.chromium.org/1696093002
Cr-Commit-Position: refs/heads/master@{#375516}
* Remove base::Tuple and make base::Tuple as an alias of std::tuple.
* Expand the alias where it's used in a class template specialization to avoid MSVC2013 internal compiler error.
BUG=554987
Review URL: https://codereview.chromium.org/1673563002
Cr-Commit-Position: refs/heads/master@{#374878}
Extending tuple confuses the compiler when we replace
base::Tuple with std::tuple.
This CL removes a base::Tuple extension and forbids it.
BUG=554987
Review URL: https://codereview.chromium.org/1462443002
Cr-Commit-Position: refs/heads/master@{#360404}
Namespace change only, no functionality change.
The only non-search-and-replace change is in generate_gmock_mutant.py which changes some line wrapping logic for the generated gmock_mutant header.
NOPRESUBMIT=true
(No presubmit due to long lines in the generated gmock_mutant.h header).
R=sky
Review URL: https://codereview.chromium.org/1159553007
Cr-Commit-Position: refs/heads/master@{#332058}
A recent Chrome change broke the /analyze builder by using a larger
Tuple than had been allowed for in the previous VC++ bug workaround.
This change unblocks the /analyze builder and will not affect
/analyze builds.
The /analyze error is:
e:\b\build\slave\chromium_windows_analyze\build\src\base\tuple.h(99) : error C2027: use of undefined type 'MakeIndexSequenceImpl<0xc>'
e:\b\build\slave\chromium_windows_analyze\build\src\device\usb\usb_device_handle_impl.cc(608)
and came from https://codereview.chromium.org/980023002R=thakis@chromium.org
BUG=427616
Review URL: https://codereview.chromium.org/1095543003
Cr-Commit-Position: refs/heads/master@{#325877}
The recently added MakeIndexSequence templates cause a VC++ internal
compiler error when building with /analyze. This happens on dozens of
source files so disabling /analyze for those files is impractical. This
change conditionally replaces the template recursion with a
straightforward implementation for values from zero to five. This is
sufficient to build Chrome at the moment.
The code which VC++ doesn't like was introduced in change:
https://codereview.chromium.org/693693005
It's an ugly fix, but justified by the desire to allow running
/analyze. The /analyze version of the code will never be run.
A VC++ bug has been filed:
https://connect.microsoft.com/VisualStudio/feedback/details/1053626
BUG=427616
Review URL: https://codereview.chromium.org/803183004
Cr-Commit-Position: refs/heads/master@{#312469}
Using "x()" in TupleLeaf's default constructor causes primitive types
(e.g., integers and pointers) to be zero initialized, whereas
previously Tuple left them indeterminate. Arguably zero-initializing
is better, but the change was inadvertant and results in a measurable
code size increase, so this CL reverts it (at least for now).
BUG=440806
Review URL: https://codereview.chromium.org/791883003
Cr-Commit-Position: refs/heads/master@{#308455}
Instead of specially implementing Tuple for 0 to 8 arguments, use a
more traditional implementation by having Tuple<A, B, ...> inherit
from TupleLeaf<0, A>, TupleLeaf<1, B>, etc. This allows Tuple to be
used with an arbitrary number of arguments.
To remain backwards compatible with code that accesses "t.a", "t.b",
etc., we specialize TupleLeaf for the first 8 elements to store their
values in appropriately named member variables. These accessors work
even for Tuples with more than 8 elements, but the 9th element and
beyond are only supported with get<N>().
Review URL: https://codereview.chromium.org/792763002
Cr-Commit-Position: refs/heads/master@{#307681}
This CL adds a generic variadic Tuple class that generalizes
Tuple1, Tuple2, etc. It also adds the C++11-style get<N>(tuple)
method for accessing tuple members. As a demonstration, the
DispatchToFunction() and DispatchToMethod() functions have been
updated to make use of these and became substantially shorter.
However, to remain compatible with existing code that accesses
Tuple fields by name, the Tuple class is actually implemented via
multiple specializations that match the TupleN classes that used
to exist. Once all access to foo.a, bar->b, ... have been updated
to get<0>(foo), get<1>(*bar), ... then we can simplify Tuple
further and eventually replace it with std::tuple.
Review URL: https://codereview.chromium.org/693693005
Cr-Commit-Position: refs/heads/master@{#307629}
When dispatching, have base::DispatchToMethod/DispatchToFunction use the
base::internal::UnwrapTraits<> to properly unwrap the base::Tuple's wrapped
argument.
This ensures that methods that expect a "T*" can be properly dispatched when
the tuple contains a scoped_refptr<T> without relying on implicit
conversions.
BUG=110610
Review URL: https://chromiumcodereview.appspot.com/17911007
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@208903 0039d316-1c4b-4281-b951-d872f2087c98
This should have been removed as a part of 71680, but seems like I overlooked it.
BUG=7327
TEST=none
Review URL: http://codereview.chromium.org/8037050
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@103063 0039d316-1c4b-4281-b951-d872f2087c98
If the client-side phishing detection classifies a page as phishing it will
send back a ping to Google to verify whether or not the page is really phishing.
If the server also classifies the site as phishing we may show a phishing
interstitial if it is enabled.
BUG=
TEST=
Review URL: http://codereview.chromium.org/6014003
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@75299 0039d316-1c4b-4281-b951-d872f2087c98
There is a new crash report but not caught by the CHECKS.
(http://crash/reportdetail?reportid=accf4c24431527ce#crashing_thread)
This could be because this ifdef generates two different objects of this template function and linker may be picking bad one.
BUG=chromium-os:7327
TEST=none
Review URL: http://codereview.chromium.org/5405003
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67913 0039d316-1c4b-4281-b951-d872f2087c98
This is chromeos only and will be removed once I correct data.
BUG=chromium-os:7327
TEST=none
Review URL: http://codereview.chromium.org/4752003
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@65729 0039d316-1c4b-4281-b951-d872f2087c98
That patch wasn't what caused the regression in the page cycler.
BUG=51411,52103
TEST=still compiles
Review URL: http://codereview.chromium.org/3106018
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@56390 0039d316-1c4b-4281-b951-d872f2087c98
This moves MessageWithTuple::Read() back into the main ipc_message_utils.h
header from the private ipc_messsage_utils_impl.h header. In release mode, this
was causing link failures.
BUG=51411
TEST=none
Review URL: http://codereview.chromium.org/3069034
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55587 0039d316-1c4b-4281-b951-d872f2087c98
The slowest cc files in chrome include render_messages.h and other IPC message
definitions. Including one of these files will bring in half of chrome because
in the IPC system previously required full class definitions due to
implementation details.
The new system allows forward declarations and places the implementations of
functions that need the full class definitions (ctor/dtor()/Log() and
superclass ctor/Read() methods) into a separate xxx_messages.cc file using a
parallel set of macros to ipc_message_macros.h. This has the added benefit
of moving most of the template instantiation junk into a small number of
files.
Pros:
- Will speed up compiling by a lot once everything is forward declared.
- Already, intermediary .o/.a files are smaller.
Cons:
- Adds a 4th pass to the messages system, this time in a different header.
BUG=51411
TEST=none
Review URL: http://codereview.chromium.org/2873090TBR=erg@google.com
Review URL: http://codereview.chromium.org/3080040
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55406 0039d316-1c4b-4281-b951-d872f2087c98
The slowest cc files in chrome include render_messages.h and other IPC message
definitions. Including one of these files will bring in half of chrome because
in the IPC system previously required full class definitions due to
implementation details.
The new system allows forward declarations and places the implementations of
functions that need the full class definitions (ctor/dtor()/Log() and
superclass ctor/Read() methods) into a separate xxx_messages.cc file using a
parallel set of macros to ipc_message_macros.h. This has the added benefit
of moving most of the template instantiation junk into a small number of
files.
Pros:
- Will speed up compiling by a lot once everything is forward declared.
- Already, intermediary .o/.a files are smaller.
Cons:
- Adds a 4th pass to the messages system, this time in a different header.
BUG=51411
TEST=none
Review URL: http://codereview.chromium.org/2873090
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55259 0039d316-1c4b-4281-b951-d872f2087c98
BUG=50273
TEST=everything still builds, build is 10% faster on windows, same speed on mac/linux
TBR: erg
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@53716 0039d316-1c4b-4281-b951-d872f2087c98
- choose better names for some helper methods
- move code to less random places
This change also adds bigger tuples support, up to Tuple8 in base/tuple.h.
The plan is to stop using such big number of parameters, but for now it's not
trivial.
This change also fixes some UI tests, not sure why it is so.
TEST=unit_tests, browser_tests, ui_tests
BUG=48913
Review URL: http://codereview.chromium.org/2805091
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@53053 0039d316-1c4b-4281-b951-d872f2087c98
sending them. This makes it so that types sendable via IPC no longer need
copy constructors.
BUG=12296
Review URL: http://codereview.chromium.org/112042
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16497 0039d316-1c4b-4281-b951-d872f2087c98
Normalize end of file newlines in base/. All files end in a single newline.
Review URL: http://codereview.chromium.org/42011
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11329 0039d316-1c4b-4281-b951-d872f2087c98
Preliminary work to enforce new PRESUBMIT.py rules:
- <=80 cols
- no trailing whitespaces
- svn:eol-style=LF
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10791 0039d316-1c4b-4281-b951-d872f2087c98
