Skip to content

some updates and fixes for clang-14 - #3794

Closed
firewave wants to merge 6 commits into
cppcheck-opensource:mainfrom
firewave:clang-14
Closed

some updates and fixes for clang-14#3794
firewave wants to merge 6 commits into
cppcheck-opensource:mainfrom
firewave:clang-14

Conversation

@firewave

@firewavefirewave commented Feb 2, 2022

Copy link
Copy Markdown
Collaborator

The unused member function warnings is probably not clang-14 specific but occurred since I did not have Z3 enabled.

I will also check and file tickets if necessary since this seems like things we should detect ourselves.

A cleanup of all the existing clang warnings will happen after the simplecpp compiler warning fixes have been merged and hit this rep.

@danmar@pfultz2 Please review the operator changes and unit test failures since you introduced that code.

@firewave
firewave marked this pull request as draft February 2, 2022 22:47
@firewavefirewave changed the title fixed some clang-14 compiler warningssome updates for clang-14Feb 5, 2022
@firewavefirewave changed the title some updates for clang-14some updates and fixes for clang-14Feb 5, 2022
@firewave

Copy link
Copy Markdown
CollaboratorAuthor

I think the compiler warnings reported in checkcondition.cpp are also detected by us but we have bitwiseOnBoolean disabled in the selfcheck.

@danmar

Copy link
Copy Markdown
Collaborator

I think the compiler warnings reported in checkcondition.cpp are also detected by us but we have bitwiseOnBoolean disabled in the selfcheck.

Yeah that is by intention. I don't agree that a boolean must never be used in a bitwise operation.


void CheckCondition::duplicateConditionError(const Token *tok1, const Token *tok2, ErrorPath errorPath)
{
if (diag(tok1) & diag(tok2))

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

as diag might be relatively expensive and as far as I see there are no desired side effects in rhs, I think a jump here makes sense.

Copy link
Copy Markdown
CollaboratorAuthor

Choose a reason for hiding this comment

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

If the intention is that both function should run (I wasn't aware the bitwise operator would not short circuit until I just read up on it) the code should reflect that. This just looks too much like a typo.

This seems to affect the output though as the unit tests now fail. I don't know if that is correct.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

If the intention is that both function should run (I wasn't aware the bitwise operator would not short circuit until I just read up on it) the code should reflect that. This just looks too much like a typo.

imho I don't agree it looks like a typo.

Comment threadlib/valueflow.cpp Outdated
ValueFlow::Value result(0);
result.condition = value1.condition ? value1.condition : value2.condition;
result.setInconclusive(value1.isInconclusive() | value2.isInconclusive());
result.setInconclusive(value1.isInconclusive() || value2.isInconclusive());

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

isInconclusive can be easily inlined here. I don't like the clang warning here.

@firewavefirewaveMar 7, 2022

Copy link
Copy Markdown
CollaboratorAuthor

Choose a reason for hiding this comment

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

I think it has to do with the bitwise operator having precedence over the logical ones so if you would use ! in there the result would be unexpected. Still this just looks like a typo to me.

@danmardanmarMar 13, 2022

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

so if you would use ! in there the result would be unexpected

That would have been unexpected to me.. but ! still has higher precedence than both the logical and bitwise and.

It is not a typo in our code to use bitwise or/and. We do that intentionally sometimes. I am against this clang warning.

Copy link
Copy Markdown
CollaboratorAuthor

Choose a reason for hiding this comment

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

I disabled it for now.

@firewave

Copy link
Copy Markdown
CollaboratorAuthor

I merged this into #4004 since that contains the actual update to clang-14 and it already had overlaps.

@firewave
firewave deleted the clang-14 branch May 11, 2022 07:49
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@firewave@danmar