After some iterations on strong class semantics, this change probably
doesn't
need to go ahead, since instances are no longer going to be sealed.
https://codereview.chromium.org/1239803004/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You
https://codereview.chromium.org/1304923004/diff/11/src/parser.cc
File src/parser.cc (right):
https://codereview.chromium.org/1304923004/diff/11/src/parser.cc#newcode4241
src/parser.cc:4241: factory()->set_zone(outer_zone);
On 2015/09/10 12:16:54, Michael Starzinger wrote:
Suggestion as
https://codereview.chromium.org/1304923004/diff/60001/src/ast.h
File src/ast.h (right):
https://codereview.chromium.org/1304923004/diff/60001/src/ast.h#newcode3280
src/ast.h:3280: : zone_(ast_value_factory->zone()),
On 2015/09/09 19:48:16, titzer wrote:
Can we rename this zone to be clearer as
https://codereview.chromium.org/1304923004/diff/180001/src/ast.h
File src/ast.h (right):
https://codereview.chromium.org/1304923004/diff/180001/src/ast.h#newcode3696
src/ast.h:3696: // HeapObjects which need to persist until scope
analysis must be allocated in
On 2015/09/10 14:06:36, Michael
Reviewers: titzer, Michael Starzinger, rossberg,
Message:
PTAL
Of the "worst" allocations mentioned here..
https://code.google.com/p/chromium/issues/detail?id=417697#c14
Allocations that are discarded:
NewAssignment, NewNumberLiteral, NewBinaryOperation, NewExpressionStatement,
NewProperty,
Reviewers: rossberg, Benedikt Meurer,
Message:
PTAL
Description:
[strong] weak classes can't inherit from strong ones
Prerequisite for sealing strong class instances.
Depends on https://codereview.chromium.org/1314203002/
BUG=v8:3956
LOG=N
Please review this at
On 2015/09/02 14:53:52, rossberg wrote:
Igor, given that Toon is away, can you perhaps have a look at this CL?
I'm not completely happy with this CL just now, I was talking to Jakob about
this issue recently and it seems like there might be a better way to do it
(plus
I've still not checked
Adding some other reviewers since rossberg is at ICFP, this is blocking a
couple
of other things.
https://codereview.chromium.org/1314203002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to
https://codereview.chromium.org/1314203002/diff/40001/test/mjsunit/strong/function-arity.js
File test/mjsunit/strong/function-arity.js (left):
https://codereview.chromium.org/1314203002/diff/40001/test/mjsunit/strong/function-arity.js#oldcode220
test/mjsunit/strong/function-arity.js:220: `'use
RecordPatternError(const
Scanner::Location& loc,
On 2015/08/27 15:32:24, conradw wrote:
> I was thinking it might be possible to eliminate/combine the
> assignment_pattern_error_ object, since every time
assignment_pattern_error_
is
> set, binding_pattern_error_ is set identically. Fro
On 2015/08/31 13:13:30, wingo wrote:
On 2015/08/31 11:22:53, conradw wrote:
> On 2015/08/28 09:54:13, wingo wrote:
> >
https://codereview.chromium.org/1309813007/diff/1/src/expression-classifier.h
> > File src/expression-classifier.h (right):
> >
> >
>
h
,
On 2015/08/27 15:16:01, caitp wrote:
On 2015/08/27 09:40:26, conradw wrote:
BindingPatternErrors and AssignmentPatternErrors being separate
seems odd to
me,
from scanning the parser code it looks like the latter implies the
former.
This
might be an opportunity to unify them somewhat
https://codereview.chromium.org/1309813007/diff/1/src/expression-classifier.h
File src/expression-classifier.h (right):
https://codereview.chromium.org/1309813007/diff/1/src/expression-classifier.h#newcode158
src/expression-classifier.h:158: void RecordPatternError(const
Scanner::Location loc,
Reviewers: rossberg,
Message:
PTAL
Description:
[es6] Make harmony_destructuring imply harmony_default_parameters
When encountering a = token in ParseAssignmentExpression, the default
parameter case is not locally distinguishable from the destructuring case.
BUG=
Please review this at
Reviewers: rossberg,
Message:
PTAL
Description:
[strong] Class constructor bodies cannot contain use strong directive
Since the constructor is also the class object itself, allowing it to
retroactively become a strong object would have unintuitive consequences
wrt the strength of the other
https://codereview.chromium.org/1300103005/diff/11/src/expression-classifier.h
File src/expression-classifier.h (right):
https://codereview.chromium.org/1300103005/diff/11/src/expression-classifier.h#newcode235
src/expression-classifier.h:235: // parameter
On 2015/08/24 13:11:08,
On 2015/08/25 12:35:32, rossberg wrote:
lgtm
this will need to wait for the other arrow stuff to be relanded, however
https://codereview.chromium.org/1300103005/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you
Reviewers: rossberg,
Message:
PTAL
Description:
[parser] partially revert use-strict directives in function body affect
init
block
TC39 agreed to disallow use strict directives in function body when
non-simple parameter lists are used.
This is a continuation of caitp's CL
::kDateField:
case Runtime::kFinalizeClassDefinition:// TODO(conradw): Is it
safe?
-case Runtime::kFinalizeClassDefinitionStrong: // TODO(conradw): Is it
safe?
case Runtime::kDefineClassMethod: // TODO(jarin): Is it
safe?
case Runtime
https://codereview.chromium.org/1270393002/diff/1/src/runtime/runtime-classes.cc
File src/runtime/runtime-classes.cc (right):
https://codereview.chromium.org/1270393002/diff/1/src/runtime/runtime-classes.cc#newcode266
src/runtime/runtime-classes.cc:266: RETURN_FAILURE_ON_EXCEPTION(isolate,
On 2015/08/05 15:17:56, conradw wrote:
oops, PTAL
https://codereview.chromium.org/1270423003/
--
--
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
Reviewers: rossberg,
Description:
[strong] dot prototypes of class literals should be strong objects
BUG=v8:3956
LOG=N
Please review this at https://codereview.chromium.org/1270423003/
Base URL: https://chromium.googlesource.com/v8/v8.git@master
Affected files (+5, -2 lines):
M
Reviewers: Michael Starzinger, rossberg,
Message:
PTAL
Description:
Move final parts of class literal setup into a single runtime call
This avoids multiple ToFastProperties runtime calls and additional stack
pushes in strong mode.
BUG=
Please review this at
Reviewers: Toon Verwaest, rossberg,
Message:
PTAL, will upload tests shortly
Description:
Bubble up the transitions associated with PreventExtensionsWithTransition
PreventExtensionsWithTransition adds special transitions which
ReconfigureProperty struggles to handle. If a single one of these
https://codereview.chromium.org/1235983002/diff/1/src/compiler/ast-graph-builder.cc
File src/compiler/ast-graph-builder.cc (right):
https://codereview.chromium.org/1235983002/diff/1/src/compiler/ast-graph-builder.cc#newcode1649
src/compiler/ast-graph-builder.cc:1649: // TODO(conradw): It would
https://codereview.chromium.org/1235883002/diff/1/test/mjsunit/strong/class-extend-null.js
File test/mjsunit/strong/class-extend-null.js (right):
https://codereview.chromium.org/1235883002/diff/1/test/mjsunit/strong/class-extend-null.js#newcode67
test/mjsunit/strong/class-extend-null.js:67:
Reviewers: rossberg,
Message:
PTAL
Description:
[strong] Strong classes can't extend null
BUG=v8:3956
Please review this at https://codereview.chromium.org/1235883002/
Base URL: https://chromium.googlesource.com/v8/v8.git@master
Affected files (+185, -36 lines):
M
, environment()-Pop()); // prototype
NewNode(op, environment()-Pop()); // literal
+ if (is_strong(language_mode())) {
+// TODO(conradw): It would be more efficient to define the properties
with
+// the right attributes the first time round.
+literal =
+NewNode(javascript
Reviewers: rossberg,
Message:
PTAL
Description:
[strong] class objects created in strong mode have their prototype frozen
BUG=v8:3956
LOG=N
Please review this at https://codereview.chromium.org/1235983002/
Base URL: https://chromium.googlesource.com/v8/v8.git@master
Affected files (+128,
Reviewers: rossberg,
Message:
PTAL
Description:
[strong] Add tests for loading from super, loading with access checks
BUG=v8:3956
LOG=N
Please review this at https://codereview.chromium.org/1219663009/
Base URL: https://chromium.googlesource.com/v8/v8.git@master
Affected files (+261, -1
childObjAccessor2 = { set foo(_){}, set 1(_){}, __proto__: proxy2 };
+
+(function() {
+ use strong;
+ // TODO(conradw): These asserts are sanity checking V8's proxy
implementation.
+ // Strong mode semantics for ES6 proxies still need to be explored.
+ assertDoesNotThrow(function(){proxy1.foo
ping
https://codereview.chromium.org/1199983002/
--
--
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
This patchset also removes one of the runtime checks for compare.
https://codereview.chromium.org/1216463003/diff/140001/src/compiler/ast-graph-builder.cc
File src/compiler/ast-graph-builder.cc (right):
https://codereview.chromium.org/1199983002/diff/180001/src/ic/ic.cc
File src/ic/ic.cc (right):
https://codereview.chromium.org/1199983002/diff/180001/src/ic/ic.cc#newcode2959
src/ic/ic.cc:2959: } // namespace v8::internal
On 2015/06/30 14:20:40, Toon Verwaest wrote:
Remove this change from
https://codereview.chromium.org/1193633003/diff/40001/test/cctest/test-api.cc
File test/cctest/test-api.cc (right):
https://codereview.chromium.org/1193633003/diff/40001/test/cctest/test-api.cc#newcode21442
test/cctest/test-api.cc:21442: TEST(StrongModeAccessChecks) {
On 2015/06/30 12:38:03,
On 2015/06/24 12:08:58, mvstanton wrote:
I just looked at the deltas beyond the original patch, and say LGTM.
I'll hold off from committing this until I get lgtm for Toon again, since I
had
to rebase over some more of his changes.
https://codereview.chromium.org/1199983002/
--
--
v8-dev
Reviewers: rossberg,
Message:
PTAL, I kind of dislike the crankshaft workaround but I can't see another
way
around the problem.
Description:
[strong] Implement strong mode semantics for the count operation.
Also fixes a crankshaft bug with strong implicit conversions.
It turns out that the
Reviewers: Toon Verwaest, mvstanton, rossberg,
Message:
PTAL, regressions should be fixed.
It may be worth waiting until after the branch cut to land this, however.
Description:
Revert Revert relanded strong property access CL
Regression issues should be solved. Initial patchset is the
https://codereview.chromium.org/1196623002/diff/40001/src/compiler/control-reducer.cc
File src/compiler/control-reducer.cc (right):
https://codereview.chromium.org/1196623002/diff/40001/src/compiler/control-reducer.cc#newcode7
src/compiler/control-reducer.cc:7: #include
Reviewers: rossberg,
Message:
PTAL
Description:
Fix overlapping KeyedLoadIC bitfield.
BUG=
Please review this at https://codereview.chromium.org/1192383003/
Base URL: https://chromium.googlesource.com/v8/v8.git@master
Affected files (+6, -2 lines):
M src/ic/ic.h
M src/ic/ic-state.h
Ah, I missed this port. LGTM, although I'm not a committer.
https://codereview.chromium.org/1191333003/
--
--
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
Reviewers: rossberg,
Message:
PTAL
Description:
Revert relanded strong property access CL
Reason:
Regressions in various benchmarks.
Revert Revert of Revert of [strong] Implement strong mode restrictions on
property access (patchset #1 id:1 of
https://codereview.chromium.org/1189153002/)
Reviewers: rossberg,
Message:
PTAL
Description:
Revert relanded strong property access CL
Reason:
Regressions in various benchmarks.
Revert Revert of Revert of [strong] Implement strong mode restrictions on
property access (patchset #1 id:1 of
https://codereview.chromium.org/1189153002/)
Reviewers: rossberg,
Message:
PTAL
Description:
[strong] Add tests for loading from proxy, super, with access checks
Followup for https://codereview.chromium.org/1168093002/
These seem to already function correctly without the need for further
runtime
changes.
There will be a final
https://codereview.chromium.org/1168093002/diff/420001/src/lookup.h
File src/lookup.h (right):
https://codereview.chromium.org/1168093002/diff/420001/src/lookup.h#newcode227
src/lookup.h:227:
On 2015/06/18 10:32:12, Toon Verwaest wrote:
spurious change
Done.
A revert of this CL (patchset #23 id:460001) has been created in
https://codereview.chromium.org/1189153002/ by conr...@chromium.org.
The reason for reverting is: Speculative revert, maybe breaks GC-stress
Reviewers: rossberg, mvstanton, Michael Starzinger, Toon Verwaest,
Message:
Created Revert of [strong] Implement strong mode restrictions on property
access
Description:
Revert of [strong] Implement strong mode restrictions on property access
(patchset #23 id:460001 of
A revert of this CL (patchset #1 id:1) has been created in
https://codereview.chromium.org/1185343005/ by conr...@chromium.org.
The reason for reverting is: Issue was ultimately caused/fixed by
https://codereview.chromium.org/1194673002/.
https://codereview.chromium.org/1189153002/
--
--
Reviewers: rossberg, mvstanton, Michael Starzinger, Toon Verwaest,
Message:
Created Revert of Revert of [strong] Implement strong mode restrictions on
property access
Description:
Revert of Revert of [strong] Implement strong mode restrictions on property
access (patchset #1 id:1 of
https://codereview.chromium.org/1177053006/diff/1/src/ast.h
File src/ast.h (right):
https://codereview.chromium.org/1177053006/diff/1/src/ast.h#newcode487
src/ast.h:487: bool ignore_completion_values() const { return
ignore_completion_values_; }
On 2015/06/18 05:43:21, rossberg wrote:
Nit: why
Reviewers: rossberg,
Message:
PTAL
Description:
[es6] Fix completion values of for loops with lexical variables
Currently, the desugaring of for loops of the form for
(let/const ...; bla; bla) causes them to always have a
completion value of 1, regardless of whether the loop body
is executed
LGTM (not that this does anything :P)
https://codereview.chromium.org/1180943007/
--
--
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
https://codereview.chromium.org/1180943007/diff/1/src/parser.cc
File src/parser.cc (right):
https://codereview.chromium.org/1180943007/diff/1/src/parser.cc#newcode2566
src/parser.cc:2566: if ((FLAG_strong_this || peek() != Token::THIS)
Could the peek() check be eliminated by shifting the flag
https://codereview.chromium.org/1180943007/diff/1/src/preparser.cc
File src/preparser.cc (right):
https://codereview.chromium.org/1180943007/diff/1/src/preparser.cc#newcode603
src/preparser.cc:603: if ((FLAG_strong_this || peek() != Token::THIS)
Similar here (sorry for spam)
LGTM
Before committing, maybe change the description of this issue to refer to
the
new test for better context.
https://codereview.chromium.org/1179763003/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are
getObjects() {
On 2015/06/11 09:36:34, rossberg wrote:
On 2015/06/10 12:03:23, conradw wrote:
On 2015/06/10 08:28:08, rossberg wrote:
Other interesting cases to add:
- arguments (both strict and sloppy)
- typed arrays
- a non-standard builtin instance (e.g. of Date)
- some builtins (Object
/mjsunit/strong/load-element-mutate-backing-store.js (right):
https://codereview.chromium.org/1168093002/diff/21/test/mjsunit/strong/load-element-mutate-backing-store.js#newcode7
test/mjsunit/strong/load-element-mutate-backing-store.js:7: //
TODO(conradw): Track implementation of strong bit for other
PTAL, all ports now completed
https://codereview.chromium.org/1168093002/
--
--
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
https://codereview.chromium.org/1168093002/diff/120001/src/code-factory.h
File src/code-factory.h (right):
https://codereview.chromium.org/1168093002/diff/120001/src/code-factory.h#newcode44
src/code-factory.h:44: LanguageMode language_mode);
On 2015/06/09 10:56:11, Michael Starzinger wrote:
https://codereview.chromium.org/1168093002/diff/140001/src/builtins.h
File src/builtins.h (right):
https://codereview.chromium.org/1168093002/diff/140001/src/builtins.h#newcode93
src/builtins.h:93: LoadICState::kStrongModeState)
\
On 2015/06/09 12:46:44, mvstanton wrote:
You
Also NORMAL - WEAK as per other comment
https://codereview.chromium.org/1144183004/diff/220001/src/compiler/js-operator.h
File src/compiler/js-operator.h (right):
https://codereview.chromium.org/1144183004/diff/220001/src/compiler/js-operator.h#newcode328
src/compiler/js-operator.h:328: const
Reviewers: rossberg, mvstanton, Michael Starzinger, Toon Verwaest,
Message:
PTAL
Description:
[strong] Implement strong mode restrictions on property access
Implements the strong mode proposal's restrictions on property access.
To be fully explored in a followup: proxies, interceptors, load
Redid the names, I like Adam's suggestion that non-strong mode should be
NORMAL, since it doesn't inspire the same confusion that seeing WEAK
scattered around in object initialization would.
I can't think of a better name for the enum itself than Strength, since
it's
already being used by
On 2015/06/04 16:20:56, adamk wrote:
On 2015/06/04 15:24:30, arv wrote:
Is there a reason we need both LanguageMode and Strength? Can we just
user
LanguageMode in the places where we use Strength?
+1 to this. From outside the strong mode work, needing to understand that
Strength::FIRM
On 2015/06/04 18:38:31, conradw wrote:
On 2015/06/04 16:20:56, adamk wrote:
On 2015/06/04 15:24:30, arv wrote:
Is there a reason we need both LanguageMode and Strength? Can we just
user
LanguageMode in the places where we use Strength?
+1 to this. From outside the strong mode work
Reviewers: rossberg, arv,
Message:
PTAL
Description:
[strong] Refactor ObjectStrength into a replacement for strong boolean args
Boolean is_strong parameters have begun to proliferate across areas where
strong mode semantics are different. This CL repurposes the existing
ObjectStrength enum as
Reviewers: rossberg, arv,
Message:
PTAL
Description:
[strong] Fix strong object exception messages
A mistake in a recent CL has messed up the error messages for strong object
semantics.
BUG=
LOG=N
Please review this at https://codereview.chromium.org/1157273008/
Base URL:
Reviewers: arv, rossberg,
Message:
PTAL
apologies for the spam, uploaded the wrong version
Description:
[strong] Fix strong object exception messages
A mistake in a recent CL has messed up the error messages for strong object
semantics.
BUG=
LOG=N
Please review this at
https://codereview.chromium.org/1152093003/diff/60001/src/globals.h
File src/globals.h (right):
https://codereview.chromium.org/1152093003/diff/60001/src/globals.h#newcode230
src/globals.h:230: FIRM // strong object
On 2015/05/28 16:11:44, arv wrote:
Why not STRONG?
This was Andreas'
With permission, I've fixed the remaining problems with this CL here:
https://codereview.chromium.org/1152093003/
https://codereview.chromium.org/1151853003/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are
Reviewers: rossberg, arv, Dmitry Lomov (ooo until Jun 8),
Message:
PTAL
Description:
[strong] create strong array literals
Copied, with permission, from https://codereview.chromium.org/1151853003/
Initial patch set is an unmodified copy, rebased on top of related fixes
from
https://codereview.chromium.org/1156573002/diff/140001/src/elements.cc
File src/elements.cc (right):
https://codereview.chromium.org/1156573002/diff/140001/src/elements.cc#newcode940
src/elements.cc:940: if (obj-map()-is_strong()
!backing_store-is_the_hole(key)) {
On 2015/05/28 15:46:17, arv
Just now, the fast path assumes you never throw, and you don't care much
about
the previous attribute values, since before strong mode it was impossible to
fail to set writable/enumerable attribute to false. I think it's possible to
modify the fast path to work, but it requires inspecting the
Reviewers: rossberg, arv,
Message:
PTAL
Description:
[strong] fix strong array, object prototypes
Strong Object/Array literals are currently being created with incorrect
internal prototypes. This CL fixes this and extends the test suite to check.
BUG=
LOG=N
Please review this at
https://codereview.chromium.org/1156573002/diff/60001/src/elements.cc
File src/elements.cc (right):
https://codereview.chromium.org/1156573002/diff/60001/src/elements.cc#newcode1405
src/elements.cc:1405: dictionary, entry, obj-map()-is_strong());
On 2015/05/22 14:01:26, rossberg wrote:
Do we
On 2015/05/27 18:09:33, conradw wrote:
https://codereview.chromium.org/1156573002/diff/60001/src/elements.cc
File src/elements.cc (right):
https://codereview.chromium.org/1156573002/diff/60001/src/elements.cc#newcode1405
src/elements.cc:1405: dictionary, entry, obj-map()-is_strong
, conradw wrote:
On 2015/05/22 13:10:28, rossberg wrote:
Nit: why care about enumerable in all these tests?
The defineProperties case needs it to work, and I can't let it
varying or it
will always throw.
Actually, I don't understand your use of defineProperties. AFAICT it
should
Reviewers: rossberg,
Message:
PTAL
Description:
Make delete API consistent for String objects
Deleting a in-bounds character index from a String object should always
return
false.
BUG=
LOG=N
Please review this at https://codereview.chromium.org/1153673003/
Base URL:
https://codereview.chromium.org/1143623002/diff/140001/src/messages.h
File src/messages.h (right):
https://codereview.chromium.org/1143623002/diff/140001/src/messages.h#newcode230
src/messages.h:230: T(StrongSetProto, Cannot set internal prototype of
strong object %)\
On 2015/05/22
https://codereview.chromium.org/1156573002/diff/40001/src/messages.h
File src/messages.h (right):
https://codereview.chromium.org/1156573002/diff/40001/src/messages.h#newcode229
src/messages.h:229: T(StrongDeleteProperty,
\
On 2015/05/22 11:34:50, rossberg wrote:
https://codereview.chromium.org/1142393003/diff/20001/src/messages.h
File src/messages.h (right):
https://codereview.chromium.org/1142393003/diff/20001/src/messages.h#newcode231
src/messages.h:231: Cannot redefine non-configurable property '%' of
strong object % to be \
On 2015/05/22
On 2015/05/18 13:46:40, rossberg wrote:
This one should definitely have a cctest for the API. Does that go
through the
JS as well?
It doesn't, so changing the runtime won't work :(. Between this and a
rebase,
I've shoved the fixed version into another CL.
Reviewers: rossberg, arv,
Message:
PTAL
Description:
[strong] Implement per-object restrictions behaviour of delete operator
Implements the strong mode proposal's restrictions on the behaviour of the
delete operator for strong objects.
Setting the strong bit is still wip, so this change will
/test/mjsunit/strong/object-freeze-property.js
@@ -0,0 +1,59 @@
+// Copyright 2015 the V8 project authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+// Flags: --strong-mode --allow-natives-syntax
+
+// TODO(conradw
PTAL, updated
https://codereview.chromium.org/1143623002/
--
--
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
@@ -0,0 +1,63 @@
+// Copyright 2015 the V8 project authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+// Flags: --strong-mode --allow-natives-syntax
+
+// TODO(conradw): Track implementation of strong bit for other
is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+// Flags: --strong-mode --allow-natives-syntax
+
+// TODO(conradw): Track implementation of strong bit for other objects, add
+// tests.
+// Currently it's pointless to actually try setting any properties before
https://codereview.chromium.org/1130283002/diff/80001/src/code-stubs.h
File src/code-stubs.h (right):
https://codereview.chromium.org/1130283002/diff/80001/src/code-stubs.h#newcode1472
src/code-stubs.h:1472: CompareICStub(Isolate* isolate, Token::Value op,
bool strong,
On 2015/05/08 13:54:36,
Reviewers: rossberg,
Message:
PTAL
Description:
[strong] Disallow implicit conversions for comparison
Implements the strong mode proposal's restrictions on implicit conversions
for the binary , =, , and = operators.
BUG=v8:3956
LOG=N
Please review this at
Reviewers: rossberg, arv,
Message:
PTAL - currently the extended test fails on the affected architectures.
Description:
[es6] Fix symbol comparison on some architectures
https://codereview.chromium.org/1125783002 did not handle all cases for some
architectures. These cases are now covered, and
On 2015/05/06 14:54:35, arv wrote:
LGTM
For once I actually ran the test on all platforms and still I missed
these. It
is really sad how much the code have diverged between the platforms.
Yes, this case is particularly miserable because the architectures that
factor
this part out into
Reviewers: rossberg,
Message:
PTAL
Description:
[strong] Fix inlining issue
The Hydrogen representation for binops was never changed to care about the
language mode. We thought this was ok, but it turns out we need to keep
track
of it to make sure inlining doesn't mess with the strongness
https://codereview.chromium.org/1109223004/diff/60001/test/mjsunit/strong/implicit-conversions.js
File test/mjsunit/strong/implicit-conversions.js (right):
https://codereview.chromium.org/1109223004/diff/60001/test/mjsunit/strong/implicit-conversions.js#newcode80
https://codereview.chromium.org/1109223004/diff/1/src/runtime.js
File src/runtime.js (right):
https://codereview.chromium.org/1109223004/diff/1/src/runtime.js#newcode163
src/runtime.js:163: //ECMA-262, section 11.6.1, page 50.
On 2015/04/30 08:43:59, Dmitry Lomov (chromium) wrote:
This comment
https://codereview.chromium.org/1109223004/diff/40001/src/compiler/js-typed-lowering.cc
File src/compiler/js-typed-lowering.cc (right):
https://codereview.chromium.org/1109223004/diff/40001/src/compiler/js-typed-lowering.cc#newcode336
src/compiler/js-typed-lowering.cc:336: if
https://codereview.chromium.org/1109223004/diff/20001/src/compiler/js-typed-lowering.cc
File src/compiler/js-typed-lowering.cc (right):
https://codereview.chromium.org/1109223004/diff/20001/src/compiler/js-typed-lowering.cc#newcode324
src/compiler/js-typed-lowering.cc:324:
Reviewers: rossberg, Michael Starzinger, Dmitry Lomov (chromium), arv,
Message:
PTAL
Description:
[strong] Disallow implicit conversions for add
Implements the strong mode proposal's restrictions on implicit conversions
for the binary + operator. Test suite is also cleaned up/refactored to
The + in the CL description was meant to refer to binary +,
instead of unary +. I've clarified. It turns out unary +,-
are gotten for free via parser re-writes, so I've added tests
for them. cctests from the last CL should already be testing
the strong versions of these ops, I was lazy last time
https://codereview.chromium.org/1084243005/diff/1/src/compiler/js-operator.cc
File src/compiler/js-operator.cc (right):
https://codereview.chromium.org/1084243005/diff/1/src/compiler/js-operator.cc#newcode281
src/compiler/js-operator.cc:281: Name##OperatorSTRICT
k##Name##StrictOperator;
Added the extra test cases, bearing in mind my comment about ++,--
@mstarzinger, are the TF changes ok?
https://codereview.chromium.org/1102923002/diff/140001/test/mjsunit/strong/implicit-conversions.js
File test/mjsunit/strong/implicit-conversions.js (right):
1 - 100 of 124 matches
Mail list logo
