Re: [24/32] module mapper

Nathan Sidwell writes: > These are needed as they also serve to inform the mapper of a dependency > edge. Ok, that makes sense (and thanks for making it optional via a flag). One thing that is still missing in this area is the dependency on stdc-predef.h. In other words, we now can get

Re: Modules doc

Marek Polacek writes: > > +Only emit the module CMI, inhibiting any object file. > > Maybe say here that CMI is Compiled Module Interface. FYI, SG15 (WG21 study group on tooling) seems to have settled on BMI ("built module interface"):

Re: [00/32] C++ 20 Modules

Nathan Sidwell writes: > It is not a complete implementation. The major missing pieces are: [...] Would now be a good time to start reporting bugs in bugzilla so that things don't fall through the cracks? Is so, would it make sense to add the "c++ modules" component to bugzilla?

Re: [24/32] module mapper

I've noticed the following issues with the module mapper in the -fdirectives-only mode: 1. When partially preprocessing the module interface unit, the mapper receives the MODULE-EXPORT request that's unnecessary (BMI is not written): g++ ... -x c++ -E -fdirectives-only -o hello.gcm.ii

Re: [04/32] cpp lexer

get set when entering it? Again, > comment at the very least. FWIW, I remember wrestling with that login in my branch, here are the changes to directives-only.c (in particular, see the "Handle import as pseudo-directive (P1703R0)" commit): https://github.com/boris-kolpackov/gcc-cxx-

Re: [00/32] C++ 20 Modules

Nathan Sidwell writes: > The repo is providing a mechanism by which two processes can synchronize > on a fixed location in the file system that is not /. You need such a > capability as the file system is the bulk transfer mechanism. > > The alternatives are to always use absolute paths, or

Re: [00/32] C++ 20 Modules

bed in this[3] WG21 paper). AFAIK, these extensions haven't yet been considered for merging into c++-modules. [1] BTW, SG15 seems to have settled on the BMI (built module interface) term instead of CMI: https://github.com/cplusplus/modules-ecosystem-tr/blob/master/definitions.tex [2]

Re: [PATCH v3] Ability to remap file names in __FILE__, etc (PR other/70268)

Ximin Luo writes: > -I to an absolute path is not that common for system / distro-built > stuff. Ok, thanks for clarifying. > In the cases that it occurs, indeed it could and should be fixed > by the package buildsystem, e.g. by stripping a prefix when they > add -I flags

Re: [PATCH v3] Ability to remap file names in __FILE__, etc (PR other/70268)

Ximin Luo <infini...@pwned.gg> writes: > Boris Kolpackov: > > > This does feel like we are trying to fix the issue in the wrong place. > > Also, won't such broken packages normally store all options (including > > -I) rather than just CFLAGS? And if the answer is

Re: [PATCH v3] Ability to remap file names in __FILE__, etc (PR other/70268)

Ximin Luo writes: > Higher-level build scripts sometimes like to save CFLAGS etc into the build > output, making the overall build output unreproducible even if GCC is playing > nicely. Rather than add logic to strip -f{file,debug,macro,...}-prefix-map, > into all possible

[COMMITTED] Add myself to MAINTAINERS (write after approval)

ChangeLog: 2018-01-18 Boris Kolpackov <bo...@codesynthesis.com> * MAINTAINERS (write after approval): Add myself. --- MAINTAINERS (revision 256843) +++ MAINTAINERS (working copy) @@ -454,6 +454,7 @@ Michael Koch <konque...@gmx.de> Ni

Re: [PATCH v4] Ability to remap file names in __FILE__, etc (PR other/70268)

bcpp/ChangeLog: 2018-01-13 Boris Kolpackov <bo...@codesynthesis.com> PR other/70268 * include/cpplib.h (cpp_callbacks::remap_filename): New callback. * libcpp/macro.c (_cpp_builtin_macro_text): Call remap_filename for __FILE__ and __BASE_FILE__. gcc/Ch

[PING 5] Ability to remap file names in __FILE__, etc (PR other/70268)

Hi, Looks like this is the last chance for this patch to make GCC 8 so I would like to ping it one last time: https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01451.html It has been reviewed (with thanks) by David Malcolm[1] and Martin Sebor[2]. Their concerns are addressed in the latest revision

[PING 4] Ability to remap file names in __FILE__, etc (PR other/70268)

Hi, I would like to again ping this patch: https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01451.html It has been reviewed (with thanks) by David Malcolm[1] and Martin Sebor[2]. Their concerns are addressed in the latest revision of the patch:

[PING 3] Ability to remap file names in __FILE__, etc (PR other/70268)

Hi, I would like to again ping this patch: https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01451.html It has been reviewed (with thanks) by David Malcolm[1] and Martin Sebor[2]. Their concerns are addressed in the latest revision of the patch:

Re: [PATCH v3] Ability to remap file names in __FILE__, etc (PR other/70268)

ry is old while preprocessing some > files. To make it 100% clear which is meant, I would find it > more accurate if it were phrased like this instead: > > When preprocessing files residing in directory @file{@var{old}}, > expand the @code{__FILE__} and @code{__BASE_FILE__} macr

Re: [PATCH v2] Ability to remap file names in __FILE__, etc (PR other/70268)

n empty prefix is a prefix of any path) and is not very useful in practice. Are you sure it's a good idea to have this noise seeing that I will have to do it for all three options? > > +#pragma message __FILE__ /* { dg-message "FILE-PREFIX" } */ > > +#pragma messag

[PING 2] Ability to remap file names in __FILE__, etc (PR other/70268)

Hi, I would like to again ping this patch: https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01451.html While the patch touches a few places, it is mostly reshuffling, generalizing, and fixing existing code. It also includes tests for the new functionality. Seeing that there is interest[1] in

[PING] Ability to remap file names in __FILE__, etc (PR other/70268)

Hi, I would like to ping this patch: https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01451.html While the patch touches quite a few places, it is mostly reshuffling and generalizing existing code. It also includes tests for the new functionality. Seeing that there is a lot of interest[1] in

Re: [PING] Plugin support on Windows/MinGW

JonY <10wa...@gmail.com> writes: > Libtool shouldn't matter since it is not used to build those, [...] We don't know which build system the plugin author will use to build the plugin. We can, however, reasonably expect that it will be able to produce a shared library with the platform-standard

Re: [PING] Plugin support on Windows/MinGW

JonY <10wa...@gmail.com> writes: > Is there a problem with using .so for internal libraries instead of > "dll"... I think not but I haven't tested it. The problem with using .so instead of .dll is that producing this non-standard extension may not be easy or possible depending on the build

[PING] Plugin support on Windows/MinGW

Hi, I would like to ping this patch: https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01040.html The changes are fairly conservative: they do not touch much of the existing module implementation and plugin support on MinGW is disabled by default (there are also fixes for a couple of bugs as a

[PATCH] Ability to remap file names in __FILE__, etc (PR other/70268)

offers a significantly different implementation though I used the original patch as a reference to make sure I've covered all the areas (e.g., __builtin_FILE()). Copyright assignment is on file. libcpp/ChangeLog: 2017-11-17 Boris Kolpackov <bo...@codesynthesis.com> PR other

[PATCH] Plugin support on Windows/MinGW

extensions). Copyright assignment is on file. [1] https://codesynthesis.com/products/odb/ [2] https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-gcc [3] https://stage.build2.org/?builds==windows_10-mingw_w64_gcc_7.2 Thanks, Boris config/ChangeLog: 2017-11-14 Boris Kolpackov <

[PATCH] Install cp/operators.def as part of plugin headers

Hi, cp/cp-tree.h now includes operators.def which means it has to be installed as part of the plugin headers. The below patch addresses this (copyright assignment is on file). Thanks, Boris gcc/cp/ChangeLog: 2017-11-07 Boris Kolpackov <bo...@codesynthesis.com> * Make-l

[PATCH] Write dependency information (-M*) even if there are errors

(working copy) @@ -1,3 +1,8 @@ +2017-08-06 Boris Kolpackov <bo...@codesynthesis.com> + + * c-opts.c (c_common_finish): Write dependency information even if + there are errors. + 2017-07-14 David Malcolm <dmalc...@redhat.com> * c-common.c (try_to_locate_new_include_insertion_