Fixing an init bug in the minified file

[PoneyClairDeLune]

Wonder why your bundler would merge the two operations into the same line...

I only read the minified file and directly fixed it. I didn't read the source code at all.

[Caligatio]

Could you describe what error you're encountering so can fix this in the source and/or build process?

I'm fairly certain your changes are around the first sub-loop in theta (Line 118 in sha3.ts). Unpacking what the minifier did, it looks like it's using a form of the comma operator that I was completely unfamiliar with until now. I think the minified code is actually correct unless, of course, you're hitting an error.

[PoneyClairDeLune]

I think the minified code is actually correct unless, of course, you're hitting an error.

Yes, I hit multiple errors when I tried using the minified module in ESBuild. After analysing the minified code, I just rewrote the section to include the declaration, and everything became normal.

In strict mode, all the variables needed must be declared before they can be used. Without the fix they will simply emit an error related to declaration. I enabled strict mode for my whole project, and non-strict behaviours errored out pretty badly, hence the fix.

[Caligatio]

I think I tracked this down to a bug in terser and have opened a ticket: terser/terser#1502

I'm not super keen on modifying anything in the dist/ directory as those are rewritten on every commit. I hope I can get this fixed upstream :)

P.S. - There's no such thing as "use strict" in ES6 modules as everything is strict per the spec.

[Caligatio]

Hi @PoneyClairDeLune

It actually appears that this might be a bug with esbuild. Looking at the prettied minimized function:

function m(t, n) {
    let r, i, s, e;
    const o = [],
        h = [];
    if (null !== t)
        for (i = 0; i < t.length; i += 2) n[(i >>> 1) % 5][(i >>> 1) / 5 | 0] = E(n[(i >>> 1) % 5][(i >>> 1) / 5 | 0], new w(t[i + 1], t[i]));
    for (r = 0; r < 24; r += 1) {
        for (e = p(), i = 0; i < 5; i += 1) o[i] = (u = n[i][0], c = n[i][1], f = n[i][2], a = n[i][3], d = n[i][4], new w(u.N ^ c.N ^ f.N ^ a.N ^ d.N, u.I ^ c.I ^ f.I ^ a.I ^ d.I));
        for (i = 0; i < 5; i += 1) h[i] = E(o[(i + 4) % 5], l(o[(i + 1) % 5], 1));
        for (i = 0; i < 5; i += 1)
            for (s = 0; s < 5; s += 1) n[i][s] = E(n[i][s], h[i]);
        for (i = 0; i < 5; i += 1)
            for (s = 0; s < 5; s += 1) e[s][(2 * i + 3 * s) % 5] = l(n[i][s], b[i][s]);
        for (i = 0; i < 5; i += 1)
            for (s = 0; s < 5; s += 1) n[i][s] = E(e[i][s], new w(~e[(i + 1) % 5][s].N & e[(i + 2) % 5][s].N, ~e[(i + 1) % 5][s].I & e[(i + 2) % 5][s].I));
        n[0][0] = E(n[0][0], A[r])
    }
    var u, c, f, a, d;
    return n
}

I learned from the terser devs that var declarations are hoisted to the top of their scope so that var declaration right before the return is completely compliant with "strict".

[PoneyClairDeLune]

@Caligatio Ouch... ESBuild by default doesn't emit let due to performance concerns regarding Safari, however since the build chain never counted for that browser, I switched to let and that seems to have triggered the temporal deadzone.
Though hoisting declarations with var instead of conforming to the temporal deadzone looks rather weird...