On Fri, Mar 8, 2019 at 8:58 AM Mathias Stearn <redbeard0531+isocpp_at_[hidden]>
wrote:

>
>
> On Fri, Mar 8, 2019 at 11:44 AM Tom Honermann <tom_at_[hidden]> wrote:
>
>>
>> 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?
>>
>> 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.
>>
> I think that is unavoidably required for modular source code. You need
> some way to keep code in each module unit separate to preserve the correct
> semantics. There is no longer a direct equivalent of a preprocessed file
> where everything is lumped into a single linear TU. Even if the delineators
> were #pragma based, such a tool would need to treat them as if they were
> single files. I think a single-stream, multi-file format (whether zip-like
> or #pragma-like since they are largely isomorphic) is the closest
> equivalent. But its also possible I'm just not creative enough to come up
> with something better, so I'm open to better suggestions, as long as they
> are semantic preserving.
>
>
-frewrite-imports generates a single file and was designed for use with
creduce/delta. The tools don't need to know anything about the markers to
get a proper reduction.

- Michael Spencer