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

Refactor check_unique to Checked{Graph,Node} #668

Open
wants to merge 1 commit into
base: kkysen/pfb/unique-checking/check-unique-refactor
Choose a base branch
from

Conversation

kkysen
Copy link
Contributor

@kkysen kkysen commented Sep 16, 2022

This refactors check_unique to Checked{Graph,Node}.

CheckedNode stores not just the NodeId like as passed to the previous check_unique, but also if it should be unique (thus we ensure we don't forget to check any Nodes (we did)), as well as the Rust source code statement for that Node as debug info.

Then CheckedGraph stores a Graph and a Vec<CheckedNode>. When .mk_* methods are called on it, it adds the CheckedNode to the Vec, and then when .check_unique() is called at the end, it uses all these CheckedNodes.

The benefits of this are:

  • The expected unique value is right next to the call that creates that Node
  • All Nodes have to be marked unique or not, so we don't forget any (we did)
  • The Rust source code statements are passed as strings for debug info instead of stored as comments. Thus, when an assert!ion fails and we print the NodeId and Graphs, we also print the Rust source code as the debug info (previously this was left blank).

@kkysen kkysen force-pushed the kkysen/pfb/unique-checking/checked-graph branch from 328afba to 449a7e3 Compare September 16, 2022 15:10
@kkysen kkysen force-pushed the kkysen/pfb/unique-checking/check-unique-refactor branch from 34bc78f to 7510aec Compare September 16, 2022 15:13
…d running `.check_unique()`. It also preserves the Rust source code in debug info.
@kkysen kkysen force-pushed the kkysen/pfb/unique-checking/checked-graph branch from 449a7e3 to ee941dd Compare September 16, 2022 15:17
@kkysen kkysen mentioned this pull request Sep 16, 2022
@kkysen kkysen requested a review from spernsteiner September 16, 2022 16:26
Copy link
Collaborator

@spernsteiner spernsteiner left a comment

Choose a reason for hiding this comment

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

Not sure this is really necessary, but it certainly doesn't hurt


let a = g.mk_addr_of_local("let mut a = 0", false, 0_u32);
let b1 = g.mk_copy("let b = &mut a", false, a);
g.mk_store_addr("*b = 0", false, b1);
Copy link
Collaborator

Choose a reason for hiding this comment

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

How about let _b2 = g.mk_store_addr(...), so the name b2 is visible here for matching with the graph above?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, I can add them back and just _-prepend them.

fn mk_node(
&mut self,
stmt: &'static str,
unique: bool,
Copy link
Contributor

Choose a reason for hiding this comment

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

nit pick: i think i'd rather this be an enum than a bool

Copy link
Contributor

Choose a reason for hiding this comment

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

optional change, just my two cents

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What's the advantage of an enum? If we're calling them Unique and NonUnique, I'm not sure there's an advantage over a bool. One is just non the other. Plus, then we should just change the unique field in NodeInfo::unique to the same enum.

Copy link
Contributor

Choose a reason for hiding this comment

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

Plus, then we should just change the unique field in NodeInfo::unique to the same enum.

I agree that should be done. My preference is because I don't like relying on IDEs to tell me what the bool represents. A type Unique or NonUnique is very clear, despite it being semantically the same as a bool. In cases where functions take more than one bool (not the case here), it prevents mixing argument order by making things type safe.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Okay, that makes sense. Plus we could change it to Unique and Aliases if we want, too. I do think we should save that for a later PR, though.

Copy link
Contributor

Choose a reason for hiding this comment

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

that sounds okay

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