Re: PATCH: Simplify resolve_nameref and setscope

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Mon, Jun 9, 2025 at 3:25 PM Philippe Altherr
<philippe.altherr@xxxxxxxxx> wrote:
>
> Could the error be caused by one of your local changes?

The error is caused because I build with --enable-zsh-debug and an
assertion fails.

> - Should builtin.c:3132 do the same gimmick as here (and a few other places in builtin.c)?

(The gimmick is to chose among gethashnode2 and gethashnode to avoid
autoloading)

I was going to ask about that eventually, because your
getparamnode_nofollow() is just gethashnode2() plus autoloading, and
I'm not sure it's ever actually necessary to do that instead of
calling gethashnode2() directly.  Furthermore (email I sent a couple
of days ago) I think it's impossible to autoload from anywhere except
realparamtab, which makes the first argument to
getparamnode_nofollow() extraneous -- that argument is only present in
gethashnode2() et al. for purposes of simulated object-orientation.

That is, function pointers in the HashTable struct are always supposed
to be called as hashtab->func(hashtab, ...) because we can't reference
"self" inside func.  In the specific case of line 3132 it's likely
guaranteed that paramtab == realparamtab.

> - Should resolve_nameref use paramtab, too?

No, a nameref can't (shouldn't) exist in any HashTable other than realparamtab.

> I'm actually surprised that "typeset" could possibly apply to something else than the real parameter table but obviously the code in builtin thinks differently.

Associative arrays are implemented by swapping out realparamtab for a
HashTable representing the association, by repointing the paramtab
global.  This was done to avoid having a massive rewrite to
parameterize all the functions that originally assumed there was only
one paramtab.