Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

assert,util: always verify both sides #30764

Closed

Conversation

@BridgeAR
Copy link
Member

BridgeAR commented Dec 2, 2019

Please have a look at the commit messages for details.

Refs: #30743

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines
BridgeAR added 2 commits Dec 2, 2019
This veryfies that both input arguments are always of the identical
type. It was possible to miss a few cases before. This change applies
to all deep equal assert functions (e.g., `assert.deepStrictEqual()`)
and to `util.isDeepStrictEqual()`.
This makes sure the assertion does not depend on the argument order.
It also removes comments that do not apply anymore and verifies the
behavior for the loose and strict implementation.
@jasnell
jasnell approved these changes Dec 2, 2019
@BridgeAR BridgeAR changed the title assert: always verify both sides assert,util: always verify both sides Dec 2, 2019
@nodejs-github-bot

This comment was marked as outdated.

if (isDate(val1)) {
if (DatePrototypeGetTime(val1) !== DatePrototypeGetTime(val2)) {
} else if (isDate(val1)) {
if (!isDate(val2) ||

This comment has been minimized.

Copy link
@ljharb

ljharb Dec 2, 2019

Member

there's no failing tests that necessitate any change to the Date or RegExp or Error or boxed primitive logic - can you add those tests?

This comment has been minimized.

Copy link
@BridgeAR

BridgeAR Dec 2, 2019

Author Member

Boxed primitives already have such test case.

I could add more tests for the other types but I actually like things like these to keep them around for coverage tasks at Code and Learn events. I am also fine to add the tests though, if you think that should be done in this PR.

This comment has been minimized.

Copy link
@ljharb

ljharb Dec 2, 2019

Member

If there's that much of a shortage of tasks for those events, then so be it, but it seems unwise to make untested changes.

This comment has been minimized.

Copy link
@BridgeAR

BridgeAR Dec 2, 2019

Author Member

I just added multiple tests and I indeed forgot to add one check 😆
There are a couple more cases that are not yet completely covered: Set, Map, ArrayBuffer and non-native errors.

@@ -1123,3 +1116,33 @@ assert.throws(
// The descriptor is not compared.
assertDeepAndStrictEqual(a, { a: 5 });
}

// Verify object types being identical on both sides.
{

This comment has been minimized.

Copy link
@ljharb

ljharb Dec 2, 2019

Member

these are the only tests that fail without your change

This comment has been minimized.

Copy link
@BridgeAR

BridgeAR Dec 2, 2019

Author Member

Yes, that is correct. The second commit is just there to prevent any further issues like these. It's somewhat independent but it fit together. Would you rather separate the two commits into two PRs?

This comment has been minimized.

Copy link
@ljharb

ljharb Dec 2, 2019

Member

nah this is fine to me, was highlighting here in reference to #30764 (comment)

if (!isEqualBoxedPrimitive(val1, val2)) {
return false;
}
} else if (ArrayIsArray(val2) ||

This comment has been minimized.

Copy link
@ljharb

ljharb Dec 2, 2019

Member

why check isArray of val2 way down here, instead of only up by the place where val1 is checked (as in #30743)?

This comment has been minimized.

Copy link
@BridgeAR

BridgeAR Dec 2, 2019

Author Member

It's less CPU work.

In #30743 all entries have to check both sides of both types. But if the arguments are e.g., sets, we'd only have to know that one side is not a set and then continue until we match sets. There we verify the other side.
If it's neither of the explicitly listed entries, we'll verify that the right side is none of the already tested types.

ljharb added a commit to inspect-js/node-deep-equal that referenced this pull request Dec 2, 2019
ljharb added a commit to inspect-js/node-deep-equal that referenced this pull request Dec 3, 2019
ljharb added a commit to inspect-js/node-deep-equal that referenced this pull request Dec 3, 2019
ljharb added a commit to inspect-js/node-deep-equal that referenced this pull request Dec 3, 2019
ljharb added a commit to inspect-js/node-deep-equal that referenced this pull request Dec 3, 2019
ljharb added a commit to inspect-js/node-deep-equal that referenced this pull request Dec 3, 2019
@ljharb

This comment has been minimized.

Copy link
Member

ljharb commented Dec 3, 2019

This LGTM as an alternative to #30743; once this lands, I'll either update my PR (if there's more tests worth adding) or close it (if there's no longer anything to add).

@Trott
Trott approved these changes Dec 5, 2019
@aks-
aks- approved these changes Dec 5, 2019
@nodejs-github-bot

This comment was marked as outdated.

@BridgeAR

This comment has been minimized.

Copy link
Member Author

BridgeAR commented Dec 6, 2019

CITGM https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/2110/ (everything seems normal).

@nodejs-github-bot

This comment has been minimized.

Copy link

nodejs-github-bot commented Dec 6, 2019

CI: https://ci.nodejs.org/job/node-test-pull-request/27406/ (yellow build with a single Windows flake. It passed in another CI run before)

BridgeAR added a commit that referenced this pull request Dec 6, 2019
This veryfies that both input arguments are always of the identical
type. It was possible to miss a few cases before. This change applies
to all deep equal assert functions (e.g., `assert.deepStrictEqual()`)
and to `util.isDeepStrictEqual()`.

PR-URL: #30764
Refs: #30743
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
BridgeAR added a commit that referenced this pull request Dec 6, 2019
This makes sure the assertion does not depend on the argument order.
It also removes comments that do not apply anymore and verifies the
behavior for the loose and strict implementation.

PR-URL: #30764
Refs: #30743
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
@BridgeAR

This comment has been minimized.

Copy link
Member Author

BridgeAR commented Dec 6, 2019

Landed in b4d48c0, b5f2942 🎉

@BridgeAR BridgeAR closed this Dec 6, 2019
targos added a commit that referenced this pull request Dec 9, 2019
This veryfies that both input arguments are always of the identical
type. It was possible to miss a few cases before. This change applies
to all deep equal assert functions (e.g., `assert.deepStrictEqual()`)
and to `util.isDeepStrictEqual()`.

PR-URL: #30764
Refs: #30743
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
targos added a commit that referenced this pull request Dec 9, 2019
This makes sure the assertion does not depend on the argument order.
It also removes comments that do not apply anymore and verifies the
behavior for the loose and strict implementation.

PR-URL: #30764
Refs: #30743
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Sebastien-Ahkrin added a commit to Sebastien-Ahkrin/node that referenced this pull request Dec 11, 2019
This veryfies that both input arguments are always of the identical
type. It was possible to miss a few cases before. This change applies
to all deep equal assert functions (e.g., `assert.deepStrictEqual()`)
and to `util.isDeepStrictEqual()`.

PR-URL: nodejs#30764
Refs: nodejs#30743
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Sebastien-Ahkrin added a commit to Sebastien-Ahkrin/node that referenced this pull request Dec 11, 2019
This makes sure the assertion does not depend on the argument order.
It also removes comments that do not apply anymore and verifies the
behavior for the loose and strict implementation.

PR-URL: nodejs#30764
Refs: nodejs#30743
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.