This is an archive of the discontinued LLVM Phabricator instance.

[analyzer][ctu] Only import const and trivial VarDecls
ClosedPublic

Authored by martong on Mar 31 2022, 5:59 AM.

Details

Summary

Do import the definition of objects from a foreign translation unit if that's type is const and trivial.

Diff Detail

Event Timeline

martong created this revision.Mar 31 2022, 5:59 AM
Herald added a project: Restricted Project. · View Herald Transcript
martong requested review of this revision.Mar 31 2022, 5:59 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 31 2022, 5:59 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript

Please add a test case where the class is trivial but the global variable of such is non-const, thus the initialized expression is not imported.

clang/include/clang/CrossTU/CrossTranslationUnit.h
112–115

definition

clang/lib/CrossTU/CrossTranslationUnit.cpp
224

extra blank line

clang/test/Analysis/Inputs/ctu-other.cpp
129

AFAIK you don't need the extern here, since this is the definition of that global, not only a declaration.
Similarly applies to the rest of the cases.

martong marked 3 inline comments as done.Mar 31 2022, 8:24 AM

Please add a test case where the class is trivial but the global variable of such is non-const, thus the initialized expression is not imported.

I've added a new case, but that is not very meaningful, because clang-extdef-mapping is not capable of emitting the USR for the non-const variable.

clang/include/clang/CrossTU/CrossTranslationUnit.h
112–115

thx, fixed.

clang/lib/CrossTU/CrossTranslationUnit.cpp
224

Thanks!

clang/test/Analysis/Inputs/ctu-other.cpp
129

Actually, linkage of const variable definitions are internal in C++, unless the extern modifier is provided. So, we need it.

If it was a non-const then the definition's linkage would be external.

martong updated this revision to Diff 419475.Mar 31 2022, 8:25 AM
martong marked 3 inline comments as done.
  • Remove blank line
  • Fix comment
  • Add new check
steakhal accepted this revision.Mar 31 2022, 11:11 AM

Please add a test case where the class is trivial but the global variable of such is non-const, thus the initialized expression is not imported.

I've added a new case, but that is not very meaningful, because clang-extdef-mapping is not capable of emitting the USR for the non-const variable.

What do you mean by not capable?

This revision is now accepted and ready to land.Mar 31 2022, 11:11 AM

Please add a test case where the class is trivial but the global variable of such is non-const, thus the initialized expression is not imported.

I've added a new case, but that is not very meaningful, because clang-extdef-mapping is not capable of emitting the USR for the non-const variable.

What do you mean by not capable?

It uses cross_tu::shouldImport() which returns true only for const declarations. So, having a hand-written extDevMapping.txt that contains an USR for a non-const is not that meaningful, imho.

Please add a test case where the class is trivial but the global variable of such is non-const, thus the initialized expression is not imported.

I've added a new case, but that is not very meaningful, because clang-extdef-mapping is not capable of emitting the USR for the non-const variable.

What do you mean by not capable?

It uses cross_tu::shouldImport() which returns true only for const declarations. So, having a hand-written extDevMapping.txt that contains an USR for a non-const is not that meaningful, imho.

I changed my mind: we can test one side of the logic if we do add extNonConstS to the externalDefMap.txt. So, just did that.

martong updated this revision to Diff 419683.Apr 1 2022, 2:25 AM
  • Add extNonConstS to the externalDefMap.txt

Please add a test case where the class is trivial but the global variable of such is non-const, thus the initialized expression is not imported.

I've added a new case, but that is not very meaningful, because clang-extdef-mapping is not capable of emitting the USR for the non-const variable.

What do you mean by not capable?

It uses cross_tu::shouldImport() which returns true only for const declarations. So, having a hand-written extDevMapping.txt that contains an USR for a non-const is not that meaningful, IMHO.

What I wanted to emphasize is that previously for all const globals it returned true, unlike now when we only return true if it's const AND trivial.
This test case would demonstrate the behavioral change and would nicely underpin the reason behind this patch.

I changed my mind: we can test one side of the logic if we do add extNonConstS to the externalDefMap.txt. So, just did that.

I don't think it's necessary, I would rather see an on-the-fly generated externalDefMap.txt to enforce that this is supposed to work all the time, even if something changes in the extdefmap tool.
Forcefully putting entries into that map is sortof like introducing dead-code, I'm not on board with that.

steakhal requested changes to this revision.Apr 1 2022, 2:45 AM
This revision now requires changes to proceed.Apr 1 2022, 2:45 AM

Please add a test case where the class is trivial but the global variable of such is non-const, thus the initialized expression is not imported.

I've added a new case, but that is not very meaningful, because clang-extdef-mapping is not capable of emitting the USR for the non-const variable.

What do you mean by not capable?

It uses cross_tu::shouldImport() which returns true only for const declarations. So, having a hand-written extDevMapping.txt that contains an USR for a non-const is not that meaningful, IMHO.

What I wanted to emphasize is that previously for all const globals it returned true, unlike now when we only return true if it's const AND trivial.
This test case would demonstrate the behavioral change and would nicely underpin the reason behind this patch.

I changed my mind: we can test one side of the logic if we do add extNonConstS to the externalDefMap.txt. So, just did that.

I don't think it's necessary, I would rather see an on-the-fly generated externalDefMap.txt to enforce that this is supposed to work all the time, even if something changes in the extdefmap tool.
Forcefully putting entries into that map is sortof like introducing dead-code, I'm not on board with that.

Currently ALL ctu tests are done with hand-written externalDefMap.txts. I agree it would be nice to generate them on-the-fly, but that should be the subject of another change. And if we do that then we will not have extNonConstS in the extdef file for this test which makes it impossible to test what you request. Please be consistent with your review.

even if something changes in the extdefmap tool

We already have a separate test file for that. That is func-mapping-test.cpp.

martong updated this revision to Diff 419702.Apr 1 2022, 3:36 AM
  • Rebase to llvm/main
martong updated this revision to Diff 419717.Apr 1 2022, 4:48 AM
  • remove extNonConstS from the externalDefMap.txt
steakhal accepted this revision.Apr 1 2022, 4:52 AM

LGTM

This revision is now accepted and ready to land.Apr 1 2022, 4:52 AM
This revision was landed with ongoing or failed builds.Apr 1 2022, 4:54 AM
This revision was automatically updated to reflect the committed changes.