[cfe-dev] Language not recognized: 'c++-module-cpp-output'

[Richard Smith via cfe-dev]

On 2 June 2017 at 00:36, Boris Kolpackov via cfe-dev <cfe-dev at lists.llvm.org
> wrote:

> Hi David,
>
> David Blaikie <dblaikie at gmail.com> writes:
>
> > So could you outline (show a small/complete example with source,
> commands,
> > etc) what you're trying to do?
>
> In build2 (build system I am working on) we have the ability to specify
> that a source file is preprocessed to a certain degree. This is used to
> speed things up. While currently having translation units that no longer
> require preprocessing is not very common, with modules (and modularized
> standard library) this situation will become a lot more plausible. So we
> want to be ready.
>
> If the user says that certain TUs are fully preprocessed, then build2
> passes this information on to the compiler via the -x option. So for C
> we say the source is '-x cpp-output' and for C++ -- '-x c++-cpp-output'.
>
> Now in Clang module interface units have to be compiled as '-x c++-module',
> not '-x c++'. So we also need '-x c++-module-cpp-output'.
>

What difference are you expecting the -cpp-output to make to the
compilation? For Clang, it does almost exactly nothing, except that we'll
consider the name from the GNU linemarker directive on the first line of
the file (if any) to be its "real" name.

We currently do not support a user-specified -cpp-output file type for any
of the formats which we support precompiling (*-header, *-module). We
certainly could if there's a good reason.

BTW, it is not clear why c++-module is needed (and it is needed -- I tried
> to compile as just c++ and things didn't go well). Perhaps now that Clang
> use the 'export module M;' syntax c++-module is no longer necessary?


It's necessary because (a) it instructs clang to build a different tool
pipeline, with a precompile stage rather than a stage that generates an
object file, and (b) under the Modules TS, the "module X;" directive has
different semantics in a module interface unit versus in a module
implementation unit -- in the latter case, it acts as a souped up form of
module import in addition to entering the semantic context of the module.

It's possible that (b) will change prior to the publication of the TS, but
we'd still need to know whether we're entering a module interface unit for
(a).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170602/27a4dd1d/attachment.html>