Since we switched to C++14 now, we can use {std::make_unique} instead
of our own {base::make_unique} from {template-utils.h}.
R=mstarzinger@chromium.org, yangguo@chromium.org
Bug: v8:9687
No-Try: true
Change-Id: I660eb30038bbb079cee93c7861cd87ccd134f01b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789300
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63642}
For macros expanding to function definitions, I removed the spurious ; after
macro invocations. For macros expandign to function declarations, I made the ;
required and consistently inserted it.
No behavior change.
Bug: chromium:926235
Change-Id: Ib8085d85d913d74307e3481f7fee4b7dc78c7549
Reviewed-on: https://chromium-review.googlesource.com/c/1467545
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59558}
gcc and clang (and the standard) don't allow implicit conversion of
function pointers to object pointers. MSVC does allow that, and since
system headers require this to work, clang-cl allows it too -- but
it emits a -Wmicrosoft-cast warning (which we currently suppress in
the Chromium build, but which we want to enable.)
As a side effect, when printing a function pointer to a stream, MSVC
(and clang-cl) will pick the operator<<(void*) overload, while gcc
and clang will pick operator<<(bool) since the best allowed conversion
they find is from function pointer to bool.
To prevent the clang-cl warning, we need to make sure that we never
directly print a function pointer to a stream. In v8, this requires
two changes:
1. Give PrintCheckOperand() an explicit specialization for function
pointers and explicitly cast to void* there. This ports
https://codereview.chromium.org/2515283002/ to V8, and also fixes a
bug on non-Windows where DCHECK() of function pointers would print
"(1 vs 1)" instead of the function's addresses.
(The bug remains with member function pointers,
where it's not clear what to print instead of the 1.)
2. has_output_operator<T> must not use operator<< on its argument
in an evaluated context if T is a function pointer. This patch
modifies has_output_operator<> to use an unevaluated context instead,
which is simpler than the current approach (and matches what Chromium's
base does), but changes behavior in minor (boring) ways
(see template-utils-unittest.cc), since operator<<() is now
called with a temporary and only operator<<() implementations callable
with a temporary are considered.
A more complicated but behavior-preserving alternative would be to
add an explicit specialization for function pointers. You can see
this variant in patch set 1 on gerrit.
Bug: chromium:550065
Change-Id: Idc2854d6c258b7fc0b959604006d8952a79eca3d
Reviewed-on: https://chromium-review.googlesource.com/940004
Commit-Queue: Nico Weber <thakis@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51636}
Before, the standard way to create a RegList was either:
RegList list = (1 << 0) | (1 << 1) | ...
or
RegList list = rax.bit() | rdx.bit() | ...
The first way allows to make the RegList constexpr, but needs comments
to document which registers you are referring to, and it has no checks
that all bits you set on the RegList actually belong to valid registers.
The second one uses the symbolic names, hence is much more readable and
makes it harder to construct invalid RegLists. It's not constexpr
though, since the {bit()} method on the register types is not constexpr.
This CL adds a constexpr accessor to get the code and bit of a
constexpr Register, and adds a helper method to create a constexpr
RegList like this:
constexpr RegList list = Register::ListOf<rax, rdx, rdi>();
This new method is used in a number of places to test its
applicability. Other uses of the old pattern remain and can be cleaned
up later.
R=tebbi@chromium.org
Change-Id: Ie7b1d6342dc5f316dcfedd0363b3540ad5e7f413
Reviewed-on: https://chromium-review.googlesource.com/728026
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48887}
In the current implementation, compilation would fail because
operator<< is not defined for enum classes. For others, the compiler
finds more than one operator<<, so it fails because it's ambiguous.
This CL fixes this by printing the integer value for enums, uses the
operator<< for all values that support it, and prints "<unprintable>"
otherwise.
Also, lots of unit tests.
R=ishell@chromium.org
Bug: v8:6837
Change-Id: I895ed226672aa07213f9605e094b87af186ec2e4
Reviewed-on: https://chromium-review.googlesource.com/671016
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48110}
I want to reuse the PassType helper in another CL, thus move it from
logging.h to template-utils.h, and rename it to pass_value_or_ref to
match other helpers there.
Also, add a boolean template parameter to declare whether array
dimensions should be removed. The default is to do so, which helps to
reduce the number of template instantiations by always passing arrays
as pointers.
Also, fix the usages in logging.h to actually use that helper when
instantiating other template functions. This will reduce the number of
instantiations.
And finally, we now have unit tests for the template utils, to document
what we expect, and test that this works on all architectures.
R=ishell@chromium.org, tebbi@chromium.org
Change-Id: I1ef5d2a489a5cfc7601c5ab13748674e3aa86cd6
Reviewed-on: https://chromium-review.googlesource.com/594247
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47191}
