TC39 Editors
2024-01-30
plaintext logs
prev next
source on github
00:30
<ljharb>
oh hm, maybe i have it in my polyfill from before it was changed, i'll update
00:32
<ljharb>

shu: separately, i'm implementing the changes to SetTypedArrayFromArrayLike in ES2024, and only one of my tests is starting to fail - it's basically this:

var ta = new Uint8Array([1, 2, 3]);
var obj = { length: 1 };
Object.defineProperty(obj, '0', { get: function () { ES.DetachArrayBuffer(ta.buffer); return 10; } });

t.throws(
	function () { ES.SetTypedArrayFromArrayLike(ta, 1, obj); },
	TypeError,
	'when a Get detaches the buffer, it throws'
);

is it possible that there's an issue in the algorithm where it's missing a detachedness check? (obv, there's always a chance the bug is in my impl, but it's pretty 1:1 with the spec text)

00:38
<shu>
why do you think it should throw?
00:38
<shu>
like, which step do you think should be throwing
00:38
<ljharb>
because it threw with the previous spec text
00:38
<shu>
ah
00:38
<ljharb>
so maybe it's just a spec bug that's now fixed, i haven't compared it to real TA code yet
00:39
<ljharb>
i mean i do see that SetTAFAL calls Get (which in this case detaches), and then it calls TypedArraySetElement, which then calls SetValueInBuffer, which then checks IsDetachedBuffer, which would throw
00:40
<shu>
i don't really know why it would throw previously
00:40
<ljharb>
because the Get detaches it, right before it tries to Set to a detached buffer. shouldn't (doesn't) it throw now too?
00:40
<shu>
ah, but see step 3 here: https://tc39.es/ecma262/#sec-typedarraysetelement
00:40
<shu>
if it's not a valid index (which no index would be, if the buffer is detached), that AO just no-ops
00:40
<ljharb>
ohhhhhhhh
00:40
<shu>
this was part of the reality alignment changes that rkirsling did a while back
00:41
<shu>
but that should predate es2024 for sure
00:41
<ljharb>
hm, ok, maybe it's a bug in my earlier implementations too then. but that suggests that at some point, the spec said to throw for this test but impls did not?
00:42
<shu>
yes, the TA stuff is famously out of sync with impl reality since it was imported from Khronos
00:42
<shu>
which is why ross proposed those changes
00:42
<ljharb>
thanks for confirming, i can dive in from here. it's probably that SetTAFromArrayLike changed at some point before 24, and i failed to update my impl to match
00:42
<shu>
famously out of sync with impl reality, specifically on what throws on detached and what no-ops, and what returns 0 etc
01:06
<bakkot>

https://github.com/tc39/ecma262/pull/2164 specifically:

IsDetachedBuffer checks should not cause the following to throw: [...]
IntegerIndexedElementSet (i.e. [[DefineOwnProperty]] and [[Set]] for typed arrays)

03:32
<bakkot>
should we back out https://github.com/tc39/ecma262/pull/3249 so we can land other stuff?
03:33
<bakkot>
that person does not appear to be active on github much
03:34
<ljharb>
yeah true. i can push up an exception for them rather than backing it out tho, if you want
03:34
<ljharb>
also i'll look into adding a status check that fails if the commit email address doesn't link to the PR's github user, since that's caused us problems a few times
03:38
<ljharb>
i'll just push up the exception
03:38
<bakkot>
wfm, but then I have never felt that it made sense to apply the contributing policy to changes like this
03:41
<ljharb>
also fair
03:42
<ljharb>
it would be interesting to figure out if the policy is only needed for normative changes - that would skip the nonsense pretty consistently
21:41
<jmdyck>
In the November editors' report, on the upcoming work page, the item "#2085 & others: replace complex spec values with spec records" is struck-through "because we have now finally finished the work of making all internal values consistent. We now use records everywhere."
21:41
<jmdyck>
But there's still Execution Contexts and Declarative Env Records.
21:41
<jmdyck>
(And maybe some others.)
23:43
<bakkot>
ah, yeah
23:43
<bakkot>
I was mostly thinking of the regex cases but you're right there's still a couple others