This is an archive of the discontinued LLVM Phabricator instance.

[clang][dataflow] Fix assert for CXXConstructExpr argument number
ClosedPublic

Authored by paulsemel on Feb 22 2023, 2:43 AM.

Details

Summary

It is permissible for a copy constructor to have additional parameters as long as they have default arguments defined for them. Regardless, it doesn't change the way we should treat those constructors in the dataflow framework.

Diff Detail

Event Timeline

paulsemel created this revision.Feb 22 2023, 2:43 AM
Herald added a project: Restricted Project. · View Herald Transcript
paulsemel requested review of this revision.Feb 22 2023, 2:43 AM
paulsemel added a project: Restricted Project.Feb 22 2023, 2:49 AM
ymandel accepted this revision.Feb 22 2023, 5:40 AM

good catch!

clang/lib/Analysis/FlowSensitive/Transfer.cpp
566

nit: please use explicit comparison: assert(S->getNumArgs() != 0).

This revision is now accepted and ready to land.Feb 22 2023, 5:40 AM
xazax.hun accepted this revision.Feb 22 2023, 8:57 AM
paulsemel updated this revision to Diff 499823.Feb 23 2023, 6:04 AM

change assert condition

paulsemel marked an inline comment as done.Feb 23 2023, 6:11 AM

Do you have permissions to commit or do you need one of us to do that for you?

Do you have permissions to commit or do you need one of us to do that for you?

I requested them again, as I used to have them back then when SVN was still around!

This revision was landed with ongoing or failed builds.Feb 24 2023, 1:52 AM
This revision was automatically updated to reflect the committed changes.

By looking at the title, I get the impression that this fixes an assertion violation.
I also observed that this commit is part of main but not part of release/16.x, hence the clang-16 would be released without this fix.

I want to raise awareness of backporting crash fixes to llvm releases. IMO that's a good practice.
So my question is, should we backport this patch to the release branch?

If so, could you please check if there are more commits like this for the dataflow library @ymandel?

I used git log release/16.x..main --oneline clang/lib/{Analysis,AST,ASTMatchers,StaticAnalyzer} clang/include/clang/{Analysis,AST,ASTMatchers,StaticAnalyzer} | grep -i 'crash\|fix\|assert' to check for relevant commits.

By looking at the title, I get the impression that this fixes an assertion violation.
I also observed that this commit is part of main but not part of release/16.x, hence the clang-16 would be released without this fix.

I want to raise awareness of backporting crash fixes to llvm releases. IMO that's a good practice.
So my question is, should we backport this patch to the release branch?

If so, could you please check if there are more commits like this for the dataflow library @ymandel?

I used git log release/16.x..main --oneline clang/lib/{Analysis,AST,ASTMatchers,StaticAnalyzer} clang/include/clang/{Analysis,AST,ASTMatchers,StaticAnalyzer} | grep -i 'crash\|fix\|assert' to check for relevant commits.

Yes, this could be backported. I'm happy to look out for this in the future, but I don't seem to have release/16.x in my git repo -- please let me know how to pull that in. I'm only responsible for Analysis/FlowSensitive, but even just there not all fixes have those search terms in there commit message.

By looking at the title, I get the impression that this fixes an assertion violation.
I also observed that this commit is part of main but not part of release/16.x, hence the clang-16 would be released without this fix.

I want to raise awareness of backporting crash fixes to llvm releases. IMO that's a good practice.
So my question is, should we backport this patch to the release branch?

If so, could you please check if there are more commits like this for the dataflow library @ymandel?

I used git log release/16.x..main --oneline clang/lib/{Analysis,AST,ASTMatchers,StaticAnalyzer} clang/include/clang/{Analysis,AST,ASTMatchers,StaticAnalyzer} | grep -i 'crash\|fix\|assert' to check for relevant commits.

Yes, this could be backported. I'm happy to look out for this in the future, but I don't seem to have release/16.x in my git repo -- please let me know how to pull that in. I'm only responsible for Analysis/FlowSensitive, but even just there not all fixes have those search terms in there commit message.

The branch I was referring to was: https://github.com/llvm/llvm-project/tree/release/16.x

For examples of how to do a backport, I would refer to the issue tracker for examples.
Look for issues with the "release:backport" label and repeat what is done there.

I think the steps are something like:

  1. Create a PR against llvm/llvm-project where you explain why you think the given change is "safe" to backport.
  2. Remember to add all the labels you feel are related.
  3. Mention any dependencies that the given commit might have that would also need to be backported prior to porting this one.
  4. Tag the code owner. I guess for you it's not relevant.
  5. Add the PR to the release "Milestone" and "Project".

Finally, reply to the PR by the /cherry-pick <hash> message so that the llvmbot will jump and try to cherry-pick the given commit to the release branch.
Usually, this will succeed without conflicts, but if you have any it tells you what to do next.

By the end of this, you will have a PR for another repo (llvm/llvm-project-release-prs), where the bot will ping the code owner for approval.

If anything goes wrong you can always tag "tstellar" or "tru" for help.
"nikic" also seems to be involved with the release process.

Note that I don't know if this is the "official" way of doing this, but so far it worked out.

Here is an example where the patch was applied cleanly: llvm/llvm-project#61097