<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 <<a href="mailto:tom@honermann.net"
moz-do-not-send="true">tom@honermann.net</a>> 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>
> 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>
><br>
> — Gaby<br>
><br>
>> On Mar 7, 2019, at 10:23 PM, Tom Honermann <<a
href="mailto:tom@honermann.net" target="_blank"
moz-do-not-send="true">tom@honermann.net</a>> wrote:<br>
>><br>
>>> On 3/5/19 11:11 AM, Ben Craig wrote:<br>
>>> 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>
>>><br>
>>> 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>
>> 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>
>><br>
>> Tom.<br>
>><br>
>>>> -----Original Message-----<br>
>>>> From: Nathan Sidwell <<a
href="mailto:nathanmsidwell@gmail.com" target="_blank"
moz-do-not-send="true">nathanmsidwell@gmail.com</a>> On
Behalf Of Nathan<br>
>>>> Sidwell<br>
>>>> Sent: Tuesday, March 5, 2019 6:04 AM<br>
>>>> To: Ben Craig <<a
href="mailto:ben.craig@ni.com" target="_blank"
moz-do-not-send="true">ben.craig@ni.com</a>>; <a
href="mailto:modules@lists.isocpp.org" target="_blank"
moz-do-not-send="true">modules@lists.isocpp.org</a>; WG21
Tooling<br>
>>>> Study Group SG15 <<a
href="mailto:tooling@open-std.org" target="_blank"
moz-do-not-send="true">tooling@open-std.org</a>><br>
>>>> Subject: [EXTERNAL] Re: [isocpp-modules]
Round2: Path to modules with old<br>
>>>> bad build systems<br>
>>>><br>
>>>>> On 3/4/19 10:02 AM, Ben Craig wrote:<br>
>>>>> I do mean textual inclusion, though I
can be convinced otherwise. Textual<br>
>>>> inclusion (with extra generated pragmas)
should make it much easier to keep<br>
>>>> tools like distcc and cppcheck happy in the
short term. I suspect that those<br>
>>>> tools don't want to crack open a BMI to
figure out which other BMIs need to<br>
>>>> be found.<br>
>>>>> Tools that (think they can) parse C++
will still need to understand these<br>
>>>> pragmas in order to provide the right
macro, visibility, and reachability<br>
>>>> behaviors, so some work will still be
required on their part, but at least they<br>
>>>> won't need to understand new binary
formats.<br>
>>>><br>
>>>> Correct, tools consuming such
#pragma-marked flattened source will need to<br>
>>>> understand modules at a fundamental level.
As such, why not implement<br>
>>>> the same mechanisms to find module source
as the compiler?<br>
>>>> That'll give them more information to
perform code analysis with.<br>
>>>><br>
>>>> nathan<br>
>>>><br>
>>>>>>> On 3/2/19 1:03 PM, Ben Craig
wrote:<br>
>>>>>>><br>
>>>>>>> Some quick notes on this
implementation strategy:<br>
>>>>>>> * Uses TEXTUAL inclusion<br>
>>>>>>> * Compiler assumes that the
build system knows nothing of BMIs<br>
>>>>>>> * Compiler needs to be able to
do module mapping with minimal input<br>
>>>>>>> from users.<br>
>>>>>> Do you literally mean textual
inclusion or do you really mean<br>
>>>>>> dynamically produce an
internal-only BMI object?<br>
>>>>>><br>
>>>>>> nathan<br>
>>>>>><br>
>>>>>> --<br>
>>>>>> Nathan Sidwell<br>
>>>> --<br>
>>>> Nathan Sidwell<br>
>>> _______________________________________________<br>
>>> Tooling mailing list<br>
>>> <a href="mailto:Tooling@isocpp.open-std.org"
target="_blank" moz-do-not-send="true">Tooling@isocpp.open-std.org</a><br>
>>> <a
href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fmailman%2Flistinfo%2Ftooling&amp;data=02%7C01%7Cgdr%40microsoft.com%7C1cdb6c203df64eb7b84408d6a38ea3ab%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876230368116236&amp;sdata=ugzbdk5BI%2Bppnt5nS0xDISJehZ3mizhZTBWDrVZZ%2BA8%3D&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;data=02%7C01%7Cgdr%40microsoft.com%7C1cdb6c203df64eb7b84408d6a38ea3ab%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876230368116236&amp;sdata=ugzbdk5BI%2Bppnt5nS0xDISJehZ3mizhZTBWDrVZZ%2BA8%3D&amp;reserved=0</a><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="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fmodules&amp;data=02%7C01%7Cgdr%40microsoft.com%7C1cdb6c203df64eb7b84408d6a38ea3ab%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876230368116236&amp;sdata=UPJ70IqxSq6PeLpRdMc7IZCotDOeyV6n7QNxOXjYFQo%3D&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;data=02%7C01%7Cgdr%40microsoft.com%7C1cdb6c203df64eb7b84408d6a38ea3ab%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876230368116236&amp;sdata=UPJ70IqxSq6PeLpRdMc7IZCotDOeyV6n7QNxOXjYFQo%3D&amp;reserved=0</a><br>
>> 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;data=02%7C01%7Cgdr%40microsoft.com%7C1cdb6c203df64eb7b84408d6a38ea3ab%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876230368116236&amp;sdata=%2BsOB4DmF0Lf6EPmsPij3i%2BsDHDZS3ujHN4S9rVjMer4%3D&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;data=02%7C01%7Cgdr%40microsoft.com%7C1cdb6c203df64eb7b84408d6a38ea3ab%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876230368116236&amp;sdata=%2BsOB4DmF0Lf6EPmsPij3i%2BsDHDZS3ujHN4S9rVjMer4%3D&amp;reserved=0</a><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/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>