<div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div>Dear LLDB Developers,</div><div><br></div><div>There is an ongoing activity to improve ASTImporter in Clang to make it support</div><div>C++ (and C) completely and correctly.  Our team works on cross translation unit</div><div>(CTU) static analysis where we use the in-tree Clang static analyzer in</div><div>combination with the ASTImporter (via the scan-build.py script or CodeChecker).</div><div>In the past 18 months we have committed more than 70 patches to make the</div><div>ASTImporter better.  Our primary target is Linux and we do run the LLDB tests</div><div>on Linux before we commit.  Unfortunately, quite recently 3 of these patches</div><div>broke the LLDB macOS buildbots (<a href="http://green.lab.llvm.org/green/view/LLDB">green.lab.llvm.org/green/view/LLDB</a>) and this</div><div>caused some turmoil.  We are very sorry about this and we are making actions to</div><div>avoid such inconveniences in the future: We ordered a Mac Mini, until it</div><div>arrives we are using a borrowed Mac Book. We are going to create a CI job which</div><div>will execute the macOS LLDB test suite for a specific patch. Besides this, for</div><div>every patch we are going to monitor the macOS buildbots once they are</div><div>committed.</div><div><br></div><div>However, we are experiencing problems both with the buildbots and with the LLDB</div><div>tests, therefore we are asking help from the LLDB community in the following:</div><div><br></div><div>(1) Apparently, the green lab macOS buildbots are not displayed in the build</div><div>bot console (<a href="http://lab.llvm.org:8011/console">http://lab.llvm.org:8011/console</a>). More importantly they are not</div><div>capable of sending emails to the authors of the commit in case of failure.</div><div>Would it be possible to setup the these buildbots to send out the emails for</div><div>the authors?</div><div><br></div><div>(2) We are facing difficulties with the LLDB lit tests both on macOS and on</div><div>Linux. E.g. on a fresh macOS mojave install, checking out master LLVM, Clang,</div><div>LLDB and then executing ninja check-lldb fails immediately.  On Linux we</div><div>experienced that some tests fail because they try to read a non-existent</div><div>register. Some tests fail non-deterministically because they can't kill a</div><div>process or a timeout is not long enough. Some tests fail because of a linker</div><div>error of libcxx. We would like to address all these issues. Would you like to</div><div>discuss these issues on lldb-dev or should we create a bugzilla ticket for</div><div>each?</div><div><br></div><div>(3) ASTImporter unit tests and lit tests in Clang for the LLDB specific usage</div><div>are very-very limited.  LLDB uses the so called "minimal" import, but none of</div><div>the unit tests exercises that (CTU uses the full import).  We should have a</div><div>unit test suite where the LLDB use cases are covered, e.g. after a minimal</div><div>import an `importDefinition` is called. Also, a test double which implements</div><div>the ExternalASTSource could be used.  I believe it would be possible to cover</div><div>with the unit tests all LLDB/macOS related scenarios and these tests could run</div><div>on Linux too.  We do something similar in case of windows: we execute all unit</div><div>tests with "-fdelayed-template-parsing" and with "-fms-compatibility" too. I</div><div>think, the more unit tests we have in Clang the sooner we catch the LLDB</div><div>specific importer errors.  I am asking the LLDB community's help here, because</div><div>we lack the domain knowledge in LLDB so we don't know what expectations should</div><div>we write in each unit test cases.  (About lit tests, there is clang-import-test</div><div>but its coverage seems pretty low and I don't know if that really exercises all</div><div>LLDB use cases.)</div><div><br></div><div>I think that from a better ASTImporter the LLDB debugger can benefit too: the</div><div>`expr` command might give better experience by supporting more C++ constructs</div><div>and by giving better diagnostics.</div><div><br></div><div>Thank you,</div><div>Gabor</div><div><br></div></div></div></div></div>