<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Hi Gabor,</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">Thank you for taking care of this
      issue!</div>
    <div class="moz-cite-prefix">I completely agree with what you said.
      In my opinion, there are also two more things we have to care
      about.</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">1. We need to involve LLDB developers
      into ASTImporter reviews. While we are familiar with the
      ASTImporter usage in CSA, LLDB developers are much more familiar
      with the usage of this component in LLDB so their opinion is
      always appreciated. If there is anybody who can participate in the
      reviews - please let us know.<br>
    </div>
    <div class="moz-cite-prefix">2. We have to get more familiar with
      LLDB ourself. The code related to the ASTImporter looks pretty
      well isolated so I think there will be no too much problems with
      it. The build bots breakage already made us take a look on the
      related components.<br>
    </div>
    <br>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">01.12.2018 19:00, Gábor Márton via
      cfe-dev пишет:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAH6rKyBTXQw9YQeTAFtgrjY_uDgHiF1-9LCOaeNyG4abMadWxA@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <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"
                  moz-do-not-send="true">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"
                  moz-do-not-send="true">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>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
cfe-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
</pre>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>