https://codereview.chromium.org/1092353002/diff/240001/src/compiler/js-operator.cc
File src/compiler/js-operator.cc (right):
https://codereview.chromium.org/1092353002/diff/240001/src/compiler/js-operator.cc#newcode233
src/compiler/js-operator.cc:233: #define CACHED_OP_LIST_WITH_STRONG(V)
\
On 2015/04/23 14:51:54, conradw wrote:
On 2015/04/23 13:47:51, Michael Starzinger wrote:
> nit: s/WITH_STRONG/WITH_LANGUAGE_MODE/
These operators are specifically associated with a macro which caches
exactly sloppy and strong versions. I wanted to avoid name oddness re.
other operators which might vary their semantics for different
combinations of language mode, and may in future get their own macros
(if StoreProperty were no longer the only operator to need a
sloppy/strict version, CACHED_OP_LIST_WITH_STRICT?)
Yep, the implementation only provides caches for SLOPPY and STRONG, but
the interface is still providing the full language mode. As for the case
that we ever need another second order macro, we can revisit the naming
then. I still think CACHED_OP_LIST_WITH_LANGUAGE_MODE makes more sense
because it best describes the interface provided for those operators.
https://codereview.chromium.org/1092353002/diff/260001/src/compiler/js-operator.h
File src/compiler/js-operator.h (right):
https://codereview.chromium.org/1092353002/diff/260001/src/compiler/js-operator.h#newcode236
src/compiler/js-operator.h:236: const Operator* UnaryNot(LanguageMode
language_mode);
The JSUnaryNot operator shouldn't require the language mode.
https://codereview.chromium.org/1092353002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
