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

check_unique refactor #667

Open
wants to merge 2 commits into
base: pfb/unique-checking
Choose a base branch
from

Conversation

kkysen
Copy link
Contributor

@kkysen kkysen commented Sep 16, 2022

Refactored all the unique and non-unique assert!ions into check_unique, which is much more concise and avoids the ton of repetition there was previously. It also adds more context to the error message when it fails.

@kkysen kkysen force-pushed the kkysen/pfb/unique-checking/check-unique-refactor branch from 3d11ec4 to 34bc78f Compare September 16, 2022 07:33
@kkysen kkysen force-pushed the kkysen/pfb/unique-checking/check-unique-refactor branch from 34bc78f to 7510aec Compare September 16, 2022 15:13
@spernsteiner
Copy link
Collaborator

One downside I see to this approach is that in some cases it forces the node names in the assertion to be out of order compared to the graph, which makes it slightly harder to match the two up. I think we could get the best of both worlds with a macro along the lines of assert_unique!(pdg, [a, !j, !b1, !b2, !c1, !c2, d2]);, or something like this:

let [a, j, b1, b2, c1, c2, d2] = unique_flags([a, j, b1, b2, c1, c2, d2]);
assert!(a && !j && !b1 && !b2 && !c1 && !c2 && d2);

@kkysen
Copy link
Contributor Author

kkysen commented Sep 16, 2022

One downside I see to this approach is that in some cases it forces the node names in the assertion to be out of order compared to the graph, which makes it slightly harder to match the two up. I think we could get the best of both worlds with a macro along the lines of assert_unique!(pdg, [a, !j, !b1, !b2, !c1, !c2, d2]);, or something like this:

let [a, j, b1, b2, c1, c2, d2] = unique_flags([a, j, b1, b2, c1, c2, d2]);
assert!(a && !j && !b1 && !b2 && !c1 && !c2 && d2);

See #668. That solves this issue I think by putting the expected unique value where we create the Node.

assert!(!info(&pdg, b3).unique);
assert!(!info(&pdg, c1).unique);
assert!(!info(&pdg, c2).unique);
check_unique(&pdg, &[], &[a, b1, b2, b3, c1, c2]);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

having these two arguments really doesn't make clear that you're checking for non-uniqueness here, in addition to the function name. i suggest having one function for each

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that might be better. Might not be worth changing, though, given #668.

Copy link
Contributor

@aneksteind aneksteind left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see comment

@kkysen
Copy link
Contributor Author

kkysen commented Sep 16, 2022

I think we could get the best of both worlds with a macro along the lines of assert_unique!(pdg, [a, !j, !b1, !b2, !c1, !c2, d2]);
I don't think we should add a macro if we don't need to.

or something like this:

let [a, j, b1, b2, c1, c2, d2] = unique_flags([a, j, b1, b2, c1, c2, d2]);
assert!(a && !j && !b1 && !b2 && !c1 && !c2 && d2);

This wouldn't give good error messages, though.

@spernsteiner
Copy link
Collaborator

This whole PR is superseded by the approach in #668, right?

@kkysen
Copy link
Contributor Author

kkysen commented Sep 16, 2022

This whole PR is superseded by the approach in #668, right?

Yeah, pretty much.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants