-
Notifications
You must be signed in to change notification settings - Fork 59
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
A7-1-2
: Query proposes to add constexpr to non-static data members (and other problems)
#789
Comments
I've a fix for (1) and (3). Requesting @lcartey to provide valuable comments! |
For (1), I think we should report non-static members, but only if they are genuinely never modified. This is because the rule states:
And the value can be determined at compile time if it's not genuinely modified. You are correct in saying that the user will also need to make the variable static in this case, in order to get the program to compile. We could potentially update the message and/or help file to explain this. For (2), CodeQL doesn't generate template members unless it needs to, so we don't get visibility into that code unless For (3), I think we discussed this separately, but the for-range-loop generated variable is wrongly flagged because we don't check that qualifiers of calls are |
Thanks @lcartey for the excellent feedback! I'll modify the PR as per your suggestions! |
Kindly check the updated PR: #794 |
Affected rules
Description
1.
constexpr
on non-static data membersThis query should exclude variables that are non-static data members. This is because the compiler raises an error in case a non-static data member is marked as
constexpr
.Example
Fixing as per the alerts raised by CodeQL in the test case of this query (e.g. here or here) also raises the error.
2.
constexpr
on member variables updated in un-instantiated templatesThis query alerts to add constexpr to member variables which are only used in uninstantiated template functions. At first glance, it seems to be correct because since the template function is not instantiated, the member variable isn't getting accessed anywhere and hence becomes a candidate for adding constexpr. However, when the user attempts to fix it, the compiler raises an error and points to the modification in the uninstantiated template function. So should we avoid member variables of templates?
Example
Note: The error about
size_
being a non-static data member and constexpr also exists but even if we make it static, we cant fix the error because compiler complains about the update onsize_
in the uninstantiated template functionadd()
.3.
constexpr
for range-based for loop variablesI'm not able to provide a reproducible case but this query alerts on variables used in range-based for loop.
Example
The reason is that when the range based for loop is de-sugared there is an assignment like the following:
We have an
operator*
as an initializer expression and it has a variable access to the__begin
variable. The line; “any(Call call | isCompileTimeEvaluatedCall(call))...” here is True for this case because theoperator *
is marked asconstexpr
by CodeQL and the getAnArgument() here for this call doesn’t return any arguments. Please note that, the qualifier for this call expression is the__begin
variable which is compiler generated. So should we avoid such calls which has a qualifier that hasVariableAccess
to variables that are compiler generated?The text was updated successfully, but these errors were encountered: