8.1.1.2.4 InitializeBinding (N,V)
InitializeBinding for object environment records seems to be unreachable.
Also applies to steps 4-6 of 8.1.1.4.4 InitializeBinding.
(I still need to look at this more closely, but I think my assumption is correct. It kind of depends how the remaining EvalDeclaration bugs were resolved. Filing now so I don't forget about this later.)
It's reachable from CreateGlobalVarBinding and
(In reply to Allen Wirfs-Brock from comment #1)
> It's reachable from CreateGlobalVarBinding and
But CreateGlobalVarBinding step 3.c should probably be removed because it's a no-op (CreateMutableBinding in step 3.a already initializes the object env binding to undefined).
(No-op is not quite correct when Realm.[[globalThis]] is a Proxy, because in that case the Put call in InitializeBinding -> SetMutableBinding is observable)
(In reply to André Bargull from comment #2)
> (In reply to Allen Wirfs-Brock from comment #1)
> > It's reachable from CreateGlobalVarBinding and
>
> But CreateGlobalVarBinding step 3.c should probably be removed because it's
> a no-op (CreateMutableBinding in step 3.a already initializes the object env
> binding to undefined).
It set the value of the property to undefined, but it doesn't record that the binding has been initialized.
The abstract definitions of CreateMutableBinding and CreateImmutableBinding in table 15 says they create uninitialized bindings. I want of their usages in algorithm to conform to that.
The note that I just added to 8.1.1.1.4. points out that the Creates are always immediately followed by the an InitializeBinding so implementation don't actually have to track the initialization state.
(In reply to Allen Wirfs-Brock from comment #4)
> (In reply to André Bargull from comment #2)
> > (In reply to Allen Wirfs-Brock from comment #1)
> > > It's reachable from CreateGlobalVarBinding and
> >
> > But CreateGlobalVarBinding step 3.c should probably be removed because it's
> > a no-op (CreateMutableBinding in step 3.a already initializes the object env
> > binding to undefined).
>
> It set the value of the property to undefined, but it doesn't record that
> the binding has been initialized.
>
> The abstract definitions of CreateMutableBinding and CreateImmutableBinding
> in table 15 says they create uninitialized bindings. I want of their usages
> in algorithm to conform to that.
>
> The note that I just added to 8.1.1.1.4. points out that the Creates are
> always immediately followed by the an InitializeBinding so implementation
> don't actually have to track the initialization state.
Does it make sense to remove 8.1.1.2.4 InitializeBinding step 4?
(In reply to André Bargull from comment #5)
> (In reply to Allen Wirfs-Brock from comment #4)
> >
> > The note that I just added to 8.1.1.1.4. points out that the Creates are
> > always immediately followed by the an InitializeBinding so implementation
> > don't actually have to track the initialization state.
>
> Does it make sense to remove 8.1.1.2.4 InitializeBinding step 4?
Actually, what might make more sense would be to put in an explicit Put() call into 8.1.1.4.18 so that a proxy like mentioned in comment #3 traces the expected traps.
BTW, if you haven't seen it, you should check out https://bugs.ecmascript.org/show_bug.cgi?id=78
fixed in rev34 editor's draft
added the Put in 8.1.1.4.18
fixed in rev34