<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Hello Aleksei,<br>
    </p>
    <p>Since everything has landed on trunk now, even with command line
      interface for CTU in clang, you can now "just launch clang" :)</p>
    <p>I have attached the configured project again with a run script
      containing the command reproducing the error.</p>
    <p>Hope this helps!<br>
    </p>
    <p>Regards<br>
      Rafael<br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 04.12.2017 17:57, Rafael·Stahl via
      cfe-dev wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:14db158d-87b8-1332-2211-5d078c7e3f0f@tum.de">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <p>Hello Aleksei,</p>
      Thank you for looking into this.<br>
      <br>
      Find attached a project of the files I mentioned in my initial
      report. If you check out something like r318000 and apply the
      current CTU patch ( <a class="moz-txt-link-freetext"
        href="https://reviews.llvm.org/D30691" moz-do-not-send="true">https://reviews.llvm.org/D30691</a>
      Diff11 is current as of writing), the issue should be visible.<br>
      <br>
      @Gábor Since I run the analyzer from a custom library: Can you
      tell Aleksei how to run scan-build on the project? As far as I
      understand it should be possible with the current patch, right?<br>
      <br>
      Regards<br>
      Rafael<br>
      <br>
      <div class="moz-cite-prefix">On 03/12/17 19:22, Aleksei Sidorin
        wrote:<br>
      </div>
      <blockquote type="cite"
        cite="mid:800f2d18-50a5-0a60-148e-bf422026e63e@samsung.com">
        <meta http-equiv="Content-Type" content="text/html;
          charset=utf-8">
        <div class="moz-cite-prefix">Hello guys,<br>
          <br>
          Do you have a reprocase I can just launch clang against? I
          have some ideas but ASTMerge and clang-import-test
          infrastructures are not very suitable for testing CSA XTU
          import strategy.<br>
          <br>
          <br>
          16.11.2017 19:42, Gábor Horváth via cfe-dev пишет:<br>
        </div>
        <blockquote type="cite"
cite="mid:CAPRL4a1NBKmCtER8XqCzsNtHJZiFWmBwXsGY9_qAAs8hFZNxyw@mail.gmail.com">
          <div dir="ltr">
            <div>
              <div>
                <div>Hi Rafael!<br>
                  <br>
                </div>
                Yeah, the cross TU patch is a great way to detect issues
                with the ASTImporter and unfortunately, those issues are
                extremely hard to debug.<br>
                <br>
              </div>
              Here, it looks like the source of the problem is that,
              when we import an EnumConstantDecl, we will import the
              EnumDecl without the typdef part.</div>
            <div>A dirty quick fix for this particular case:</div>
            <div><br>
            </div>
            <div>@@ -1782,6 +1807,11 @@ Decl
              *ASTNodeImporter::VisitEnumConstantDecl(EnumConstantDecl
              *D) {<br>
                 DeclarationName Name;<br>
                 SourceLocation Loc;<br>
                 NamedDecl *ToD;<br>
              +  auto *ED =
              cast<EnumDecl>(D->getDeclContext());<br>
              +  if (auto *TND = ED->getTypedefNameForAnonDecl()) {<br>
              +    if (!Importer.Import(TND))<br>
              +      return nullptr;<br>
              +  }<br>
                 if (ImportDeclParts(D, DC, LexicalDC, Name, ToD, Loc))<br>
                   return nullptr;<br>
                 if (ToD)<br>
              <br>
            </div>
            <div>I did not have time yet to deep dive into this and look
              at what the proper solution would be. Are you willing to
              continue to investigate this?</div>
            <div><br>
            </div>
            <div>Regards,</div>
            <div>Gábor<br>
            </div>
          </div>
          <div class="gmail_extra"><br>
            <div class="gmail_quote">On 13 November 2017 at 12:16,
              Rafael·Stahl via cfe-dev <span dir="ltr"><<a
                  href="mailto:cfe-dev@lists.llvm.org" target="_blank"
                  moz-do-not-send="true">cfe-dev@lists.llvm.org</a>></span>
              wrote:<br>
              <blockquote class="gmail_quote" style="margin:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex">Deal
                all<br>
                <br>
                While using the static analyzer with cross translation
                unit support ( <a
                  href="https://reviews.llvm.org/D30691"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">https://reviews.llvm.org/D3069<wbr>1</a>
                ), I stumbled upon an issue that is most likely related
                to the ASTImporter.<br>
                <br>
                I'm using a custom checker, but this should be
                reproduced by just running the scan-build tool.<br>
                <br>
                A simple reproducing example:<br>
                <br>
                main.c:<br>
                <br>
                ------------------------------<wbr>---------<br>
                void foo();<br>
                void moo();<br>
                <br>
                int main()<br>
                {<br>
                    foo();<br>
                    moo();<br>
                }<br>
                ------------------------------<wbr>---------<br>
                <br>
                foo.c:<br>
                <br>
                ------------------------------<wbr>---------<br>
                #include "thing.h"<br>
                <br>
                void foo()<br>
                {<br>
                    (void)THING_VALUE;<br>
                }<br>
                <br>
                void conflict(thing_t type)<br>
                {<br>
                }<br>
                ------------------------------<wbr>---------<br>
                <br>
                moo.c:<br>
                <br>
                ------------------------------<wbr>---------<br>
                #include "thing.h"<br>
                <br>
                void moo()<br>
                {<br>
                    conflict(THING_VALUE);<br>
                }<br>
                ------------------------------<wbr>---------<br>
                <br>
                thing.h:<br>
                <br>
                ------------------------------<wbr>---------<br>
                typedef enum {<br>
                    THING_VALUE<br>
                } thing_t;<br>
                <br>
                void conflict(thing_t type);<br>
                ------------------------------<wbr>---------<br>
                <br>
                Notes on particularities of this example:<br>
                <br>
                - main.c needs to NOT include the header<br>
                - main() needs to call the functions in this order<br>
                - foo() needs to reference the enumerator<br>
                - the enum needs to be typedef'd<br>
                <br>
                If any of the above points do not apply, the issue does
                not appear.<br>
                <br>
                The issue:<br>
                <br>
                ------------------------------<wbr>---------<br>
                In file included from moo.c:1:<br>
                thing.h:1:9: warning: type 'thing_t' has incompatible<br>
                      definitions in different translation units [-Wodr]<br>
                typedef enum {<br>
                        ^<br>
                thing.h:2:5: note: enumerator 'THING_VALUE' with value 0
                here<br>
                    THING_VALUE<br>
                    ^<br>
                thing.h:1:9: note: no corresponding enumerator here<br>
                foo.c:8:6: error: external function 'conflict' declared<br>
                      with incompatible types in different translation
                units ('void (thing_t)' vs. 'void (thing_t)')<br>
                void conflict(thing_t type)<br>
                     ^<br>
                thing.h:5:6: note: declared here with type<br>
                      'void (thing_t)'<br>
                void conflict(thing_t type);<br>
                     ^<br>
                ------------------------------<wbr>---------<br>
                <br>
                After importing conflict(thing_t) the ASTImporter
                compared the imported one with the original by
                structural equivalence. This reveals that in the
                imported enum the enumerators are missing, causing the
                above error.<br>
                <br>
                In my real code, not this example, I was unable to dump
                the imported EnumDecl, because it eventually calls
                SourceManager::isBeforeInTrans<wbr>lationUnit with two
                SourceLocations from different files. Not sure if this
                is related.<br>
                <br>
                I have tried adding:<br>
                <br>
                for (const auto Enumerator : D->enumerators())<br>
                    D2->addDecl(Importer.Import(En<wbr>umerator));<br>
                <br>
                before completing the definition in
                ASTNodeImporter::VisitEnumDecl<wbr>(), but that results
                in:<br>
                <br>
                exe: tools/clang/lib/AST/DeclBase.c<wbr>pp:1374: void
                clang::DeclContext::addHiddenD<wbr>ecl(clang::Decl*):
                Assertion `!D->getNextDeclInContext() && D !=
                LastDecl && "Decl already inserted into a
                DeclContext"' failed.<br>
                <br>
                I'm not familiar enough with the ASTImporter to help
                myself further here. Does anyone know what could be the
                issue?<br>
                <br>
                Best regards<span class="HOEnZb"><font color="#888888"><br>
                    Rafael Stahl<br>
                    <br>
                    <br>
                  </font></span><br>
                ______________________________<wbr>_________________<br>
                cfe-dev mailing list<br>
                <a href="mailto:cfe-dev@lists.llvm.org"
                  moz-do-not-send="true">cfe-dev@lists.llvm.org</a><br>
                <a
                  href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
                <br>
              </blockquote>
            </div>
            <br>
          </div>
          <br>
          <fieldset class="mimeAttachmentHeader"></fieldset>
          <br>
          <pre wrap="">_______________________________________________
cfe-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cfe-dev@lists.llvm.org" moz-do-not-send="true">cfe-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" moz-do-not-send="true">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
</pre>
        </blockquote>
        <p><br>
        </p>
        <pre class="moz-signature" cols="72">-- 
Best regards,
Aleksei Sidorin,
SRR, Samsung Electronics
</pre>
      </blockquote>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <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>
    <br>
  </body>
</html>