assert: fix deepEqual RangeError: Maximum call stack size exceeded

[rmdm]

Fixes: #13314
Refs: #6416

Checklist

• make -j4 test passes
• tests are included

Affected core subsystem(s)

assert

[Fishrock123]

CI: https://ci.nodejs.org/job/node-test-pull-request/8377/

I'm a bit confused as to how this fixes it, though.

[cjihrig]

The CI seems to not like this change.

[Trott]

/cc @addaleax, @joyeecheung

[rmdm]

Ouch. Somehow I mistakenly thought that $ python tools/test.py -J --mode=release parallel/test-assert would run all the test files with that prefix. And it's not. Thats my fail, shame on me, sorry...

Btw, it seems like the only failing case is the following:

AssertionError [ERR_ASSERTION]: Set { [ 1, 2 ], [ 3, 4 ] } deepEqual Set { [ 3, 4 ], [ 1, 2 ] }
    at assertDeepAndStrictEqual (/home/d/p/node/test/parallel/test-assert-deep.js:124:10)
    at Object.<anonymous> (/home/d/p/node/test/parallel/test-assert-deep.js:159:1)

And it's strange... will investigate.

[joyeecheung]

I think the failed test case is caused by memos.expected.map.get(expected) returning undefined? To make sure the two are visited in the same order, we need to first make sure expected has actually been visited before, so this should not return false when expected has not been visited (memos.expected.map.get(expected) === undefined).

[rmdm]

Thank you for the point. I tried it and indeed, it makes the case pass. However, at first, it breaks (or changes expectations of the) test added by the PR from "throws" to "not throws", which is probably not a bad thing, but rather a point that requires some discussion. Secondly, I was able to create a case that still fails:

var a = [ 1, 2 ]
var b = [ 3, 4 ]
var c = [ 1, 2 ]
var d = [ 3, 4 ]

assertDeepAndStrictEqual({
  v: a,
  s: new Set([a, b])
}, {
  v: c,
  s: new Set([d, c])
});

[rmdm]

I have changed memos semantics from tracking all currently visited nodes of an object tree to tracking visited nodes of only current branch, which brings intended semantics of tracking cycles. After that all assert-related tests passed (though some of non assert-related were failed on my machine even before my changes even on master branch - that's why I used not make test but that python script). Feeling like ready for reviews and probably CI.

[jasnell]

New CI: https://ci.nodejs.org/job/node-test-pull-request/8418/

[jasnell]

CI failure is unrelated

[jasnell]

Landed in b1ed55f

[MylesBorins]

This does not land cleanly in LTS. Please feel free to manually backport. Please also feel free to replace the backport request label with do-not-land if it shouldn't land

[Trott]

Please also feel free to replace the backport request label with do-not-land if it shouldn't land

@MylesBorins Note that people who are not in the Collaborators team cannot add or remove labels. So if a PR is authored by a non-Collaborator, perhaps ask the contributor to comment instead of replacing a label.

[gibfahn]

Agreed. @MylesBorins it's probably also worth adding the link to the backporting guide

This is my saved reply:

Should this be backported to v6.x-staging? If yes please follow the guide and raise a backport PR, if no let me know or add the dont-land-on label.

Maybe we should have a stock one.