This is an archive of the discontinued LLVM Phabricator instance.

[clang][ASTImporter] Remove use of ParentMapContext.
ClosedPublic

Authored by balazske on Oct 25 2022, 7:14 AM.

Details

Summary

Function 'isAncestorDeclContextOf' was using 'ParentMapContext' for
looking up parent of statement nodes. There may be cases (bugs?) with
ParentMapContext when parents of specific statements are not found.
This leads to 'ASTImporter' infinite import loops when function
'hasAutoReturnTypeDeclaredInside' returns false incorrectly.
A real case was found but could not be reproduced with test code.
Use of 'ParentMapContext' is now removed and changed to a more safe
(currently) method by searching for declarations in statements
and find parent of these declarations. The new code was tested on
a number of projects and no related crash was found.

Diff Detail

Event Timeline

balazske created this revision.Oct 25 2022, 7:14 AM
Herald added a reviewer: shafik. · View Herald Transcript
Herald added a project: Restricted Project. · View Herald Transcript
balazske requested review of this revision.Oct 25 2022, 7:14 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 25 2022, 7:14 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
martong accepted this revision.Oct 25 2022, 8:37 AM

It is very good that we can get rid of the ParentMapContext because it was sub-optimal to build that up for all declaration contexts of the translation unit. Now we discover the parent-child relations for ourselves and only for the needed declaration contexts. This is the proper way to go.

This revision is now accepted and ready to land.Oct 25 2022, 8:37 AM

This is really a NFC-like change but not NFC because it has visible effects of removing some crashes. I could not produce a test that provokes the wrong case (when getParents returns an empty list). Is it enough to have no new test here? If we can get a test for the crash it needs more investigation to check if RecursiveASTVisitor works correct and probably a fix at other place.

This is really a NFC-like change but not NFC because it has visible effects of removing some crashes. I could not produce a test that provokes the wrong case (when getParents returns an empty list). Is it enough to have no new test here? If we can get a test for the crash it needs more investigation to check if RecursiveASTVisitor works correct and probably a fix at other place.

In my opinion, this case a very rare case when the change is justified even without the tests. Of course, it would be better if you had a test that is a minimal reproducer for the crash you are talking about. But, since you remove a sub-optimal infrastructural element, that is the parent map, which relies on the mentioned RecursiveASTVisitor, I don't think that we need to hunt down bugs for those components that you just dumped out from the ASTImporter code.

This revision was automatically updated to reflect the committed changes.