Skip to content

Conversation

rdmarsh2
Copy link
Contributor

No description provided.

@rdmarsh2 rdmarsh2 requested a review from a team as a code owner May 28, 2020 22:50
@rdmarsh2 rdmarsh2 requested a review from a team as a code owner May 29, 2020 21:43
@rdmarsh2 rdmarsh2 added the C++ label Jun 1, 2020
Copy link
Contributor

@jbj jbj left a comment

Choose a reason for hiding this comment

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

Otherwise LGTM. It's great to see how existing tests are improving!

result = TIndirectReturnKind(-1) and
primary.isThisIndirection()
or
result = TIndirectReturnKind(primary.getParameter().getIndex())
Copy link
Contributor

Choose a reason for hiding this comment

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

This is an example of how this gets second-class treatment compared to other parameters and still needs to be special-cased. The synthetic varargs parameter is even easier to forget.

How can we make it easier to treat synthetic and non-synthetic parameters uniformly, without having to enumerate all types of synthetic parameters every time? Create an IRParameter class? Create a ReturnIndirectionInstruction.getParameterIndex() predicate and rename getParameter to getASTParameter so it's clearer that it may not always return a value?

Is one of these things easy enough to be done as part of this PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think we'd want to do both of those, and make the same getASTParameter change to the initialization instructions and argument operands. That's enough that I'd rather merge this as-is and do a sweeping parameter change separately.

@jbj
Copy link
Contributor

jbj commented Jun 5, 2020

I re-triggered the tests, and they are now failing. I'm guessing it's because of semantic merge conflicts with #3602 (trivial) and #3123 (complicated).

@rdmarsh2
Copy link
Contributor Author

rdmarsh2 commented Jun 5, 2020

Yes, semantic merge conflicts. All the merge changes are positive, with the exception of a few conversions without locations being treated as sinks. I've removed those sinks in a separate commit.

@jbj
Copy link
Contributor

jbj commented Jun 8, 2020

I've started https://jenkins.internal.semmle.com/job/Changes/job/CPP-Differences/1181/, hoping that our Jenkins workers are in better shape this morning than they were last night.

The test changes look great! I hope the CPP-Differences will live up to that.

@rdmarsh2
Copy link
Contributor Author

rdmarsh2 commented Jun 8, 2020

The new cpp/unbounded-write results in the CPP-Differences are all false positives - the length of the strcpy is bounded because the output argument of fgets is bounded. The added edges all look accurate, though.

rdmarsh2 added 2 commits June 11, 2020 13:21
The IR false positives are due to the same path length limit as the AST
false positives on the same line.
@rdmarsh2 rdmarsh2 requested a review from jbj June 12, 2020 19:08
@jbj
Copy link
Contributor

jbj commented Jun 16, 2020

LGTM, but there's a merge conflict.

@jbj jbj merged commit a87ff80 into github:master Jun 17, 2020
jbj added a commit to jbj/ql that referenced this pull request Jun 22, 2020
There was unfortunately a semantic merge conflict between github#3419 and
 github#3587 that caused a performance regression on (at least) OpenJDK.

This reverts commit 982fb38, reversing
changes made to b841cac.
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.

2 participants