<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Hi Rafael,<br>
      <br>
      This should already be fixed in upstream:
      <a class="moz-txt-link-freetext" href="https://reviews.llvm.org/D44079">https://reviews.llvm.org/D44079</a>,
      <a class="moz-txt-link-freetext" href="https://reviews.llvm.org/rL330704">https://reviews.llvm.org/rL330704</a>. Or is it still possible to
      reproduce the issue?<br>
      <br>
      <br>
      03.05.2018 16:00, Rafael·Stahl пишет:<br>
    </div>
    <blockquote type="cite"
      cite="mid:2a3aebaa-70f4-2db6-a2ca-09bb33253136@tum.de">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <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" 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>
      <br>
    </blockquote>
    <p><br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Best regards,
Aleksei Sidorin,
SRR, Samsung Electronics
</pre>
  </body>
</html>