<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 3/8/19 11:07 AM, Mathias Stearn
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAH4rMhi9H9=xOC8ETbj_Fyun=-gJC+cgrZFb9vEZBKu-svTG3Q@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div dir="ltr"><br>
        </div>
        <br>
        <div class="gmail_quote">
          <div dir="ltr" class="gmail_attr">On Fri, Mar 8, 2019 at 5:45
            AM Tom Honermann &lt;<a href="mailto:tom@honermann.net"
              moz-do-not-send="true">tom@honermann.net</a>&gt; wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex">On 3/8/19 2:28 AM,
            Gabriel Dos Reis via Modules wrote:<br>
            &gt; I prefer the suggestion of a zip file containing the
            required files much better.<br>
            <br>
            The zip approach has advantages in terms of being able to
            reproduce <br>
            preprocesor issues (assuming the issue doesn't have to do
            with resolving <br>
            header names to files of course).<br>
            <br>
            However, the zip approach doesn't work well for test case
            reduction <br>
            tools like Delta [1] or C-reduce [2] that need to mutate the
            files.  Use <br>
            with them would require exploding the zip.  If the zip file
            contains <br>
            files at absolute paths (e.g., under /usr/include), then the
            files can't <br>
            be exploded to their natural locations thus requiring
            additional <br>
            modifications to the compiler invocation to use alternate
            include paths <br>
            - which can affect test case reduction.<br>
          </blockquote>
          <div><br>
          </div>
          <div>Actually, I would expect it to be *easier* for them.
            Those tools will be able to read the files in the zip (or
            other format)  directly without ever writing them to disk.
            There are plenty of libraries for that. If this format is
            accepted as stdin to compilers, those tools should be able
            to synthesize a new stream in memory and then shove it in to
            the compiler without writing a single file to the filesystem
            until it has found the minimal repro to output. What do you
            expect will make this harder?<br>
          </div>
        </div>
      </div>
    </blockquote>
    <p>These tools operate on single files today.  In the zip case, they
      would now need to mutate not one file, but the collection of files
      within the zip archive.</p>
    <p>Tom.<br>
    </p>
    <blockquote type="cite"
cite="mid:CAH4rMhi9H9=xOC8ETbj_Fyun=-gJC+cgrZFb9vEZBKu-svTG3Q@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <div> </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex">
            <br>
            At Coverity, we do a fair amount of test case reduction in
            this way, so <br>
            it is quite important to us.<br>
            <br>
            Tom.<br>
            <br>
            [1]: <a href="http://delta.tigris.org/" rel="noreferrer"
              target="_blank" moz-do-not-send="true">http://delta.tigris.org/</a><br>
            [2]: <a href="http://embed.cs.utah.edu/creduce/"
              rel="noreferrer" target="_blank" moz-do-not-send="true">http://embed.cs.utah.edu/creduce/</a><br>
            <br>
            &gt;<br>
            &gt; — Gaby<br>
            &gt;<br>
            &gt;&gt; On Mar 7, 2019, at 10:23 PM, Tom Honermann &lt;<a
              href="mailto:tom@honermann.net" target="_blank"
              moz-do-not-send="true">tom@honermann.net</a>&gt; wrote:<br>
            &gt;&gt;<br>
            &gt;&gt;&gt; On 3/5/19 11:11 AM, Ben Craig wrote:<br>
            &gt;&gt;&gt; I will concede that static analysis tools and
            other tools that try to parse C++ probably don't need a
            textual inclusion format, since they most likely need to be
            able to parse and understand the pragmas anyway.  If module
            mapping is sufficiently straightforward, then those tools
            can do module lookup the same as a compiler.  Those tools
            already need to do include lookup in the same way that
            compilers do.<br>
            &gt;&gt;&gt;<br>
            &gt;&gt;&gt; I think the textual inclusion format will still
            be very useful to distribution and caching tools though, as
            they don't need to understand the code.  Those tools
            frequently lean on the compiler's preprocessor today, and
            don't know how to do include lookups.<br>
            &gt;&gt; Another use case is reproducing issues encountered
            in the field. Static analysis tools like Coverity need to
            emulate other compilers.  Today, when we fail to parse a TU
            that the emulated compiler accepts, we ask customers to send
            us preprocessed output for reproduction and analysis
            purposes.  We ask for preprocessed output because that is
            much simpler to handle than the entire collection of
            included header files that must then be arranged according
            to some specific compiler invocation and set of include
            paths.  We need a solution for this that works for modules
            as well.  Clang's -frewrite-imports option so far seems to
            do the job for us and it uses #pragma directives in similar
            manner to those described here.  I strongly favor specifying
            a common set of #pragma directives for this purpose.<br>
            &gt;&gt;<br>
            &gt;&gt; Tom.<br>
            &gt;&gt;<br>
            &gt;&gt;&gt;&gt; -----Original Message-----<br>
            &gt;&gt;&gt;&gt; From: Nathan Sidwell &lt;<a
              href="mailto:nathanmsidwell@gmail.com" target="_blank"
              moz-do-not-send="true">nathanmsidwell@gmail.com</a>&gt; On
            Behalf Of Nathan<br>
            &gt;&gt;&gt;&gt; Sidwell<br>
            &gt;&gt;&gt;&gt; Sent: Tuesday, March 5, 2019 6:04 AM<br>
            &gt;&gt;&gt;&gt; To: Ben Craig &lt;<a
              href="mailto:ben.craig@ni.com" target="_blank"
              moz-do-not-send="true">ben.craig@ni.com</a>&gt;; <a
              href="mailto:modules@lists.isocpp.org" target="_blank"
              moz-do-not-send="true">modules@lists.isocpp.org</a>; WG21
            Tooling<br>
            &gt;&gt;&gt;&gt; Study Group SG15 &lt;<a
              href="mailto:tooling@open-std.org" target="_blank"
              moz-do-not-send="true">tooling@open-std.org</a>&gt;<br>
            &gt;&gt;&gt;&gt; Subject: [EXTERNAL] Re: [isocpp-modules]
            Round2: Path to modules with old<br>
            &gt;&gt;&gt;&gt; bad build systems<br>
            &gt;&gt;&gt;&gt;<br>
            &gt;&gt;&gt;&gt;&gt; On 3/4/19 10:02 AM, Ben Craig wrote:<br>
            &gt;&gt;&gt;&gt;&gt; I do mean textual inclusion, though I
            can be convinced otherwise.  Textual<br>
            &gt;&gt;&gt;&gt; inclusion (with extra generated pragmas)
            should make it much easier to keep<br>
            &gt;&gt;&gt;&gt; tools like distcc and cppcheck happy in the
            short term.  I suspect that those<br>
            &gt;&gt;&gt;&gt; tools don't want to crack open a BMI to
            figure out which other BMIs need to<br>
            &gt;&gt;&gt;&gt; be found.<br>
            &gt;&gt;&gt;&gt;&gt; Tools that (think they can) parse C++
            will still need to understand these<br>
            &gt;&gt;&gt;&gt; pragmas in order to provide the right
            macro, visibility, and reachability<br>
            &gt;&gt;&gt;&gt; behaviors, so some work will still be
            required on their part, but at least they<br>
            &gt;&gt;&gt;&gt; won't need to understand new binary
            formats.<br>
            &gt;&gt;&gt;&gt;<br>
            &gt;&gt;&gt;&gt; Correct, tools consuming such
            #pragma-marked flattened source will need to<br>
            &gt;&gt;&gt;&gt; understand modules at a fundamental level. 
            As such, why not implement<br>
            &gt;&gt;&gt;&gt; the same mechanisms to find module source
            as the compiler?<br>
            &gt;&gt;&gt;&gt; That'll give them more information to
            perform code analysis with.<br>
            &gt;&gt;&gt;&gt;<br>
            &gt;&gt;&gt;&gt; nathan<br>
            &gt;&gt;&gt;&gt;<br>
            &gt;&gt;&gt;&gt;&gt;&gt;&gt; On 3/2/19 1:03 PM, Ben Craig
            wrote:<br>
            &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
            &gt;&gt;&gt;&gt;&gt;&gt;&gt; Some quick notes on this
            implementation strategy:<br>
            &gt;&gt;&gt;&gt;&gt;&gt;&gt; * Uses TEXTUAL inclusion<br>
            &gt;&gt;&gt;&gt;&gt;&gt;&gt; * Compiler assumes that the
            build system knows nothing of BMIs<br>
            &gt;&gt;&gt;&gt;&gt;&gt;&gt; * Compiler needs to be able to
            do module mapping with minimal input<br>
            &gt;&gt;&gt;&gt;&gt;&gt;&gt; from users.<br>
            &gt;&gt;&gt;&gt;&gt;&gt; Do you literally mean textual
            inclusion or do you really mean<br>
            &gt;&gt;&gt;&gt;&gt;&gt; dynamically produce an
            internal-only BMI object?<br>
            &gt;&gt;&gt;&gt;&gt;&gt;<br>
            &gt;&gt;&gt;&gt;&gt;&gt; nathan<br>
            &gt;&gt;&gt;&gt;&gt;&gt;<br>
            &gt;&gt;&gt;&gt;&gt;&gt; --<br>
            &gt;&gt;&gt;&gt;&gt;&gt; Nathan Sidwell<br>
            &gt;&gt;&gt;&gt; --<br>
            &gt;&gt;&gt;&gt; Nathan Sidwell<br>
            &gt;&gt;&gt; _______________________________________________<br>
            &gt;&gt;&gt; Tooling mailing list<br>
            &gt;&gt;&gt; <a href="mailto:Tooling@isocpp.open-std.org"
              target="_blank" moz-do-not-send="true">Tooling@isocpp.open-std.org</a><br>
            &gt;&gt;&gt; <a
href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fmailman%2Flistinfo%2Ftooling&amp;amp;data=02%7C01%7Cgdr%40microsoft.com%7C1cdb6c203df64eb7b84408d6a38ea3ab%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876230368116236&amp;amp;sdata=ugzbdk5BI%2Bppnt5nS0xDISJehZ3mizhZTBWDrVZZ%2BA8%3D&amp;amp;reserved=0"
              rel="noreferrer" target="_blank" moz-do-not-send="true">https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fmailman%2Flistinfo%2Ftooling&amp;amp;data=02%7C01%7Cgdr%40microsoft.com%7C1cdb6c203df64eb7b84408d6a38ea3ab%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876230368116236&amp;amp;sdata=ugzbdk5BI%2Bppnt5nS0xDISJehZ3mizhZTBWDrVZZ%2BA8%3D&amp;amp;reserved=0</a><br>
            &gt;&gt;<br>
            &gt;&gt; _______________________________________________<br>
            &gt;&gt; Modules mailing list<br>
            &gt;&gt; <a href="mailto:Modules@lists.isocpp.org"
              target="_blank" moz-do-not-send="true">Modules@lists.isocpp.org</a><br>
            &gt;&gt; Subscription: <a
href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fmodules&amp;amp;data=02%7C01%7Cgdr%40microsoft.com%7C1cdb6c203df64eb7b84408d6a38ea3ab%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876230368116236&amp;amp;sdata=UPJ70IqxSq6PeLpRdMc7IZCotDOeyV6n7QNxOXjYFQo%3D&amp;amp;reserved=0"
              rel="noreferrer" target="_blank" moz-do-not-send="true">https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fmodules&amp;amp;data=02%7C01%7Cgdr%40microsoft.com%7C1cdb6c203df64eb7b84408d6a38ea3ab%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876230368116236&amp;amp;sdata=UPJ70IqxSq6PeLpRdMc7IZCotDOeyV6n7QNxOXjYFQo%3D&amp;amp;reserved=0</a><br>
            &gt;&gt; Link to this post: <a
href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fmodules%2F2019%2F03%2F0218.php&amp;amp;data=02%7C01%7Cgdr%40microsoft.com%7C1cdb6c203df64eb7b84408d6a38ea3ab%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876230368116236&amp;amp;sdata=%2BsOB4DmF0Lf6EPmsPij3i%2BsDHDZS3ujHN4S9rVjMer4%3D&amp;amp;reserved=0"
              rel="noreferrer" target="_blank" moz-do-not-send="true">https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fmodules%2F2019%2F03%2F0218.php&amp;amp;data=02%7C01%7Cgdr%40microsoft.com%7C1cdb6c203df64eb7b84408d6a38ea3ab%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876230368116236&amp;amp;sdata=%2BsOB4DmF0Lf6EPmsPij3i%2BsDHDZS3ujHN4S9rVjMer4%3D&amp;amp;reserved=0</a><br>
            &gt; _______________________________________________<br>
            &gt; Modules mailing list<br>
            &gt; <a href="mailto:Modules@lists.isocpp.org"
              target="_blank" moz-do-not-send="true">Modules@lists.isocpp.org</a><br>
            &gt; Subscription: <a
              href="http://lists.isocpp.org/mailman/listinfo.cgi/modules"
              rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.isocpp.org/mailman/listinfo.cgi/modules</a><br>
            &gt; Link to this post: <a
              href="http://lists.isocpp.org/modules/2019/03/0220.php"
              rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.isocpp.org/modules/2019/03/0220.php</a><br>
            <br>
            <br>
            _______________________________________________<br>
            Modules mailing list<br>
            <a href="mailto:Modules@lists.isocpp.org" target="_blank"
              moz-do-not-send="true">Modules@lists.isocpp.org</a><br>
            Subscription: <a
              href="http://lists.isocpp.org/mailman/listinfo.cgi/modules"
              rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.isocpp.org/mailman/listinfo.cgi/modules</a><br>
            Link to this post: <a
              href="http://lists.isocpp.org/modules/2019/03/0226.php"
              rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.isocpp.org/modules/2019/03/0226.php</a><br>
          </blockquote>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
Modules mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Modules@lists.isocpp.org">Modules@lists.isocpp.org</a>
Subscription: <a class="moz-txt-link-freetext" href="http://lists.isocpp.org/mailman/listinfo.cgi/modules">http://lists.isocpp.org/mailman/listinfo.cgi/modules</a>
Link to this post: <a class="moz-txt-link-freetext" href="http://lists.isocpp.org/modules/2019/03/0229.php">http://lists.isocpp.org/modules/2019/03/0229.php</a>
</pre>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>