Tests for proposed Annex B semantics #969

littledan · 2017-04-12T12:01:49Z

No description provided.

leobalter · 2017-04-12T18:33:54Z

harness/propertyHelper.js

-    return !Object.prototype.hasOwnProperty.call(obj, name);
+    var result = !Object.prototype.hasOwnProperty.call(obj, name);
+    // Restore property (no-op if not deleted)
+    Object.defineProperty(obj, name, descriptor);


We've already discussed this before in other issues.

I don't think we should re-add the property. Once it's used, it should be consumed in the sense of atomic unit tests. To test anything in top of that, another set of object/properties would be recommended instead.

We can't avoid the side effect a configurable property will be deleted. This operation is not only restoring it, but triggering a [[DefineOwnProperty]] operation and this might cause other side effects in other test files.

If I'm not wrong, @bterlson was in those other discussions about this.

OK, I guess that could come up if you are using a Proxy that there are other side effects, but for ordinary objects, there should be no side effect to deleting a property and re-adding it the same way.

Anyway, sure, we can leave a side effect in this one, but in that case, could we put something else in propertyHelper.js to test for a non-configurable property and not mutate the object? This would be useful to allow for the multiple observations of the same property on the same object (as in the tests in the following patch). Note that we can still not be sure that it won't be side-effecting in the case of Proxies, however.

while it might not leave side effects beyond Proxies, it's beyond the responsibility for verifyConfigurable restore a state, as an extra step. Tests should follow the minimum possible steps to confirm an assertion. The best of all options would be removing the delete operation, but that's necessary as we already found parts where the descriptor was not matching the actual configurability of a property.

If the property is sent to be tested it should be consumed and that's it.

There's also the problem with non extensible objects:

Object.preventExtensions(Object); delete Object.length; Object.defineProperty(Object, 'length', { value: 42 }); // will throw

Oh right, you can delete properties from non-extensible objects. Sorry for my confusion.

Well, would you object to adding a function which just does the test and doesn't do the delete? I'd like to use a factored-out verifyConfiguable, and adding the property back in my test feels like a layering violation (who would think that a function with that name would delete a property? It feels like depending on an implementation detail).

Well, would you object to adding a function which just does the test and doesn't do the delete?

I agree with you this would be the proper approach. I really want to have some that only checks for Object.getOwnPropertyDescriptor(obj, 'prop').configurable;, but that's when we got the history of finding false positives from runtimes.

I have plans to create an easier to consume harness api for properties, where I would verify it like:

verifyProperty(obj, 'prop', { configurable: false, enumerable: true, writable: false });

So the tests won't need to worry about the order. e.g. verifyWritable being called after verifyConfigurable.

Using this same function, we can extend it with options, let's say:

verifyProperty(obj, 'prop', { configurable: false, enumerable: true, writable: false }, { descriptorOnly: true // avoid changing the actual values or deleting properties });

or even:

verifyProperty(obj, 'prop', { configurable: false, enumerable: true, writable: false, __descriptorOnly: true });

The function signature is only a bikeshed, but a new PR for it might be a good starting point to discuss the options.

Does it work for you?

No, because in this test I check property attributes of the same property multiple times from different places.

I changed this to have a restore option instead, which is doing exactly what you're doing here, but now in the new API: #979

leobalter · 2017-04-12T18:40:23Z

src/annex-b-fns/global-existing-global-init.case

+  configurable: false
+});
+
+$.evalScript(`


$262.evalScript, but I wonder if we can't just use eval

Oh oops, will fix.

We need to be eval'ing another script; this has different behavior. I'm getting at the global case in this test, not the eval behavior. test262 is actually missing coverage of other properties of Annex B 3.3 extensions to GlobalDeclarationInstantiation.

thanks for the clarification.

leobalter · 2017-04-13T15:07:54Z

the indentation fixes from a621155 found a small git conflict - whitespace only.

leobalter · 2017-04-14T16:33:01Z

I was trying to find side effects from the new verifyConfigurable api and found this file only failing with the new approach.

test/built-ins/TypedArrays/internals/DefineOwnProperty/non-extensible-redefine-key.js

rwaldron · 2017-04-14T16:37:09Z

src/annex-b-fns/global-existing-global-init.case

+verifyEnumerable(fnGlobalObject(), 'f');
+verifyWritable(fnGlobalObject(), 'f');
+verifyNotConfigurable(fnGlobalObject(), 'f');
+`)


rwaldron · 2017-04-14T16:37:22Z

src/annex-b-fns/global-existing-global-init.case

+verifyEnumerable(fnGlobalObject(), 'f');
+verifyWritable(fnGlobalObject(), 'f');
+verifyNotConfigurable(fnGlobalObject(), 'f');
+`)


rwaldron · 2017-04-14T16:37:34Z

src/annex-b-fns/global-existing-non-enumerable-global-init.case

+verifyNotEnumerable(fnGlobalObject(), 'f');
+verifyWritable(fnGlobalObject(), 'f');
+verifyConfigurable(fnGlobalObject(), 'f');
+`)


rwaldron · 2017-04-14T17:09:51Z

...nguage/eval-code/direct/global-block-decl-eval-global-existing-non-enumerable-global-init.js

+  verifyNotEnumerable(global, "f");\
+  verifyWritable(global, "f");\
+  verifyConfigurable(global, "f");{ function f() {  } }'
+);


For new multi-line strings, I recommend that we stick to template strings (I also recognize that this came from existing code). Same for all occurences

leobalter · 2018-02-15T22:01:11Z

@littledan do you have any plans to move the normative change further on ecma262? I can help with the fixes here when it's time for an update.

littledan · 2018-02-15T22:23:03Z

Sorry for dropping the ball on the review feedback here. I believe this patch has consensus and is just waiting on fixing up the code review feedback to land.

leobalter · 2018-02-15T22:38:21Z

no problem, I might be able to work on this tomorrow. I'll ping you back then.

littledan · 2018-02-16T08:05:05Z

Thanks for your help!

These tests are againt a proposed fix for tc39/ecma262#753 They seem to pass in V8, JSC and SpiderMonkey, though ChakraCore hews slightly closer to the previous specification.

littledan · 2018-03-07T23:55:42Z

Updated tests to address all of the code review comments (except @rwaldron 's suggestion to change from ' to ` in orthogonal template files, which doesn't need to be part of this patch). PTAL.

rwaldron · 2018-05-11T19:46:26Z

@littledan @leobalter sorry for letting this sit for so long. I've followed the chain of issues and PRs, all the back to the notes and verified that this does have consensus, so I will get this landed today.

Updates verified

rwaldron · 2018-05-11T19:50:35Z

Landed

leobalter · 2018-05-11T20:13:29Z

Sorry for dropping the ball on the review feedback here. I believe this patch has consensus and is just waiting on fixing up the code review feedback to land.

@littledan can you help me pointing to the consensus part? I felt a bit lot trying to find it, maybe in the notes docs?

leobalter · 2018-05-11T20:47:25Z

I found the link to the consensus but it's so weird the notes are not well captured...

12.i.k Sloppy function hoisting web reality tweak
(Daniel Ehrenberg)

Explainer
DE: (Presenting Explainer)

DE: Let's defer this.

Conclusion/Resolution
Consensus

littledan mentioned this pull request Apr 12, 2017

Annex B.3.3.3 should not unconditionally overwrite global bindings with undefined in EvalDeclarationInstantiation tc39/ecma262#753

Closed

leobalter suggested changes Apr 12, 2017

View reviewed changes

leobalter previously requested changes Apr 12, 2017

View reviewed changes

leobalter added awaiting specification test generation labels Apr 12, 2017

rwaldron reviewed Apr 14, 2017

View reviewed changes

littledan added 2 commits March 8, 2018 00:53

Add templated tests for new proposed Annex B semantics

37762b0

These tests are againt a proposed fix for tc39/ecma262#753 They seem to pass in V8, JSC and SpiderMonkey, though ChakraCore hews slightly closer to the previous specification.

Generate tests

88a673b

littledan force-pushed the fix-function-annex-b branch from 5989fe1 to 88a673b Compare March 7, 2018 23:54

rwaldron approved these changes May 11, 2018

View reviewed changes

rwaldron closed this May 11, 2018

rwaldron mentioned this pull request May 11, 2018

Normative: Create global properties for sloppy function hosting as vars tc39/ecma262#888

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tests for proposed Annex B semantics #969

Tests for proposed Annex B semantics #969

littledan commented Apr 12, 2017

leobalter Apr 12, 2017

littledan Apr 12, 2017

leobalter Apr 12, 2017

littledan Apr 13, 2017

leobalter Apr 13, 2017

littledan Apr 13, 2017

leobalter Apr 15, 2017

leobalter Apr 12, 2017

littledan Apr 12, 2017

leobalter Apr 12, 2017

leobalter commented Apr 13, 2017 •

edited

leobalter commented Apr 14, 2017

rwaldron Apr 14, 2017

rwaldron Apr 14, 2017

rwaldron Apr 14, 2017

rwaldron Apr 14, 2017 •

edited

leobalter commented Feb 15, 2018

littledan commented Feb 15, 2018

leobalter commented Feb 15, 2018

littledan commented Feb 16, 2018

littledan commented Mar 7, 2018

rwaldron commented May 11, 2018

rwaldron commented May 11, 2018

leobalter commented May 11, 2018

leobalter commented May 11, 2018

Tests for proposed Annex B semantics #969

Tests for proposed Annex B semantics #969

Conversation

littledan commented Apr 12, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

leobalter commented Apr 13, 2017 • edited

leobalter commented Apr 14, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rwaldron Apr 14, 2017 • edited

Choose a reason for hiding this comment

leobalter commented Feb 15, 2018

littledan commented Feb 15, 2018

leobalter commented Feb 15, 2018

littledan commented Feb 16, 2018

littledan commented Mar 7, 2018

rwaldron commented May 11, 2018

rwaldron commented May 11, 2018

leobalter commented May 11, 2018

leobalter commented May 11, 2018

leobalter commented Apr 13, 2017 •

edited

rwaldron Apr 14, 2017 •

edited