Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Refactorcheck_unique toChecked{Graph,Node}#668

Open
kkysen wants to merge1 commit intokkysen/pfb/unique-checking/check-unique-refactor
base:kkysen/pfb/unique-checking/check-unique-refactor
Choose a base branch
Loading
fromkkysen/pfb/unique-checking/checked-graph

Conversation

kkysen
Copy link
Contributor

This refactorscheck_unique toChecked{Graph,Node}.

CheckedNode stores not just theNodeId like as passed to the previouscheck_unique, but also if it should be unique (thus we ensure we don't forget to check anyNodes (we did)), as well as the Rust source code statement for thatNode as debug info.

ThenCheckedGraph stores aGraph and aVec<CheckedNode>. When.mk_* methods are called on it, it adds theCheckedNode to theVec, and then when.check_unique() is called at the end, it uses all theseCheckedNodes.

The benefits of this are:

  • The expectedunique value is right next to the call that creates thatNode
  • AllNodes have to be markedunique 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 anassert!ion fails and we print theNodeId andGraphs, we also print the Rust source code as the debug info (previously this was left blank).

@kkysenkkysenforce-pushed thekkysen/pfb/unique-checking/checked-graph branch from328afba to449a7e3CompareSeptember 16, 2022 15:10
@kkysenkkysenforce-pushed thekkysen/pfb/unique-checking/check-unique-refactor branch from34bc78f to7510aecCompareSeptember 16, 2022 15:13
…d running `.check_unique()`. It also preserves the Rust source code in debug info.
@kkysenkkysenforce-pushed thekkysen/pfb/unique-checking/checked-graph branch from449a7e3 toee941ddCompareSeptember 16, 2022 15:17
@kkysenkkysen mentioned this pull requestSep 16, 2022
Copy link
Collaborator

@spernsteinerspernsteiner 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 aboutlet _b2 = g.mk_store_addr(...), so the nameb2 is visible here for matching with the graph above?

Copy link
ContributorAuthor

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
ContributorAuthor

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 anenum? If we're calling themUnique andNonUnique, I'm not sure there's an advantage over abool. One is just non the other. Plus, then we should just change theunique field inNodeInfo::unique to the sameenum.

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 typeUnique orNonUnique is very clear, despite it being semantically the same as abool. 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
ContributorAuthor

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 toUnique andAliases 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 freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@aneksteindaneksteindaneksteind approved these changes

@spernsteinerspernsteinerspernsteiner approved these changes

@boyland-pfboyland-pfAwaiting requested review from boyland-pf

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

3 participants
@kkysen@spernsteiner@aneksteind

[8]ページ先頭

©2009-2025 Movatter.jp