Skip to content

C++: replace ReturnValue nodes in flow paths #7796

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

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

rdmarsh2
Copy link
Contributor

Improves data flow path readability for C++ by hiding the per-function ReturnValue nodes and forcing the nodes created for each ReturnStmt to be included in the displayed path. This also adds a new nodeIsShown predicate to the data flow library's per-language interface.

@github-actions github-actions bot added the C++ label Jan 31, 2022
@rdmarsh2
Copy link
Contributor Author

Opened as draft so I can do performance evaluations and get input from the data flow library maintainers.

@MathiasVP
Copy link
Contributor

We could hack this without changing the shared library by repurposing the CastNode class. However, I do like having a Please show this node in the final path feature that's more explicit than just marking everything as cast nodes when debugging paths 👍.

@aschackmull
Copy link
Contributor

Ah, right, yeah I see the problem you're trying to solve. I think we ought to solve this entirely within the shared library without the need for a new interface predicate.

@aschackmull
Copy link
Contributor

Do you envision other use-cases for a "Please show this node in the final path"-feature? Because I'm leaning towards considering the specific short-coming around synthesised return nodes as a bug in the shared library, which can be fixed without such a feature.

@MathiasVP
Copy link
Contributor

Do you envision other use-cases for a "Please show this node in the final path"-feature? Because I'm leaning towards considering the specific short-coming around synthesised return nodes as a bug in the shared library, which can be fixed without such a feature.

The return node use-case is the only one I've encountered so far, at least. Can you think of other use-cases @rdmarsh2?

@rdmarsh2
Copy link
Contributor Author

rdmarsh2 commented Feb 2, 2022

I didn't envision any other use-cases. If you can make a shared library fix for it, that's better than adding a new predicate to the interface.

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

Successfully merging this pull request may close these issues.

3 participants