Skip to content

Conversation

nickrolfe
Copy link
Contributor

  • adds member_function_this_type to the dbscheme (there's a corresponding extractor PR to populate this).
  • an upgrade script to approximate how the extractor populate this table.
  • adds the MemberFunction::getTypeOfThis() predicate
  • adds a test for this new predicate
  • updates expected test outputs where the type of this was not previously in the database.

Closes https://github.com/github/codeql-c-extractor-team/issues/71

@nickrolfe nickrolfe added C++ depends on internal PR This PR should only be merged in sync with an internal Semmle PR labels Jun 26, 2020
@nickrolfe nickrolfe requested a review from a team as a code owner June 26, 2020 10:53
Copy link

@dbartol dbartol left a comment

Choose a reason for hiding this comment

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

Nice. A couple minor suggestions.

@nickrolfe
Copy link
Contributor Author

I just tested the upgrade script on a Chromium database, and it was not particularly fast, maybe somewhere around 40 seconds.

dbartol
dbartol previously approved these changes Jun 26, 2020
Copy link

@dbartol dbartol left a comment

Choose a reason for hiding this comment

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

LGTM, but some tests are still failing

@nickrolfe
Copy link
Contributor Author

The tests on this PR fail because they don't run with the updated extractor. They pass on the internal/extractor PR - we should wait for Ian/Matt to review that and merge the two PRs at the same time.

@@ -70,6 +70,13 @@ class MemberFunction extends Function {
result = getADeclarationEntry() and result != getDefinition()
)
}

/**
* Gets the type of the `this` parameter associated with this member function, if any.
Copy link
Contributor

Choose a reason for hiding this comment

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

It might be nice to spell out how this is different from getDeclaringType(), i.e. being a pointer and, I can see from the test, potential for const and volatile specifiers.

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've updated the comment, but this raises an interesting question.

The member_function_this_type and the extractor allow, in principle, for any kind of Type. In practice, it's always going to be a PointerType. We could consider changing the return type of this predicate.

Copy link
Contributor

Choose a reason for hiding this comment

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

Changing to PointerType sounds good to me.

void f() {
global++;
}
};
Copy link
Contributor

Choose a reason for hiding this comment

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

Might be worth adding a couple of template classes, one that gets instantiated and one that doesn't, too.

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've added that. For the instantiated one, we get results for both the instantiation and the template. For the uninstantiated one, we get no results.

@@ -0,0 +1,6 @@
import cpp

query predicate thisExprType(ThisExpr e, Type t) { t = e.getType() }
Copy link
Contributor

Choose a reason for hiding this comment

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

Is thisExprType needed?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There didn't seem to be any existing tests for ThisExpr, so I thought it prudent to add it as well.

Copy link
Contributor

@matt-gretton-dann matt-gretton-dann left a comment

Choose a reason for hiding this comment

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

Following conversation is Slack re @jbj being happy for the type change being a follow-up - approving.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C++ depends on internal PR This PR should only be merged in sync with an internal Semmle PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants