[Bug c++/105467] New: Dependency file produced by C++ modules causes Ninja errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467 Bug ID: 105467 Summary: Dependency file produced by C++ modules causes Ninja errors Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jpakkane at gmail dot com Target Milestone: --- Currently if you try to build C++ modules using Ninja and a dependency file, things fail with this fairly cryptic error message (that comes from Ninja): inputs may not also have inputs The commend line is this: g++ -Igcc/modtest.p -Igcc '-I../test cases/unit/85 cpp modules/gcc' -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -std=c++20 -O0 -g -fmodules-ts -MD -MQ gcc/modtest.p/src0.cxx.o -MF gcc/modtest.p/src0.cxx.o.d -o gcc/modtest.p/src0.cxx.o -c '../test cases/unit/85 cpp modules/gcc/src0.cxx and the generated dependency file looks like this: gcc/modtest.p/src0.cxx.o gcm.cache/M0.gcm: \ ../test\ cases/unit/85\ cpp\ modules/gcc/src0.cxx \ /usr/include/stdc-predef.h gcc/modtest.p/src0.cxx.o gcm.cache/M0.gcm: M1.c++m M0.c++m: gcm.cache/M0.gcm .PHONY: M0.c++m gcm.cache/M0.gcm:| gcc/modtest.p/src0.cxx.o CXX_IMPORTS += M1.c++m This sets things up so that the object file depends on the sources and the generated module file depends on the object file only. Ninja does not like this and errors out because it thinks that outputs (the .o file in this case) may not be used as a dependency to other outputs. A possible fix would be to set the dependencies of the module output to be the same source files as are used for the object file. Something like this: gcc/modtest.p/src0.cxx.o gcm.cache/M0.gcm: \ ../test\ cases/unit/85\ cpp\ modules/gcc/src0.cxx \ /usr/include/stdc-predef.h gcc/modtest.p/src0.cxx.o gcm.cache/M0.gcm: M1.c++m M0.c++m: gcm.cache/M0.gcm .PHONY: M0.c++m gcm.cache/M0.gcm: \ ../test\ cases/unit/85\ cpp\ modules/gcc/src0.cxx \ /usr/include/stdc-predef.h CXX_IMPORTS += M1.c++m The corresponding Ninja bug is here: https://github.com/ninja-build/ninja/issues/1962
[Bug c++/105467] Dependency file produced by C++ modules causes Ninja errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467 --- Comment #2 from jpakkane at gmail dot com --- It would be preferable to have the default work out of the box than having every end user having to add compiler flags to make things work. Ninja is the most popular underlying build system for modules, having it work by default would make things easier for many people.
[Bug c++/105467] Dependency file produced by C++ modules causes Ninja errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467 --- Comment #4 from jpakkane at gmail dot com --- As a build system developer I'd like that the most common usage (i.e. using Ninja) would be the default and work without extra compiler flags.
[Bug c++/105467] Dependency file produced by C++ modules causes Ninja errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467 --- Comment #6 from jpakkane at gmail dot com --- According to C++ foundation's developer survey [1] the most popular build system for C++ projects is CMake by quite a massive margin. Based on personal experience almost everybody uses CMake's Ninja backend rather than the Make backend on unixy platforms simply because it is so much faster CMake does not support modules in the Make backend [2]. Some people even claim that properly supporting Make to build C++ modules is not possible if you want to make it actually production quality and reliable. Modules are very much a forward looking thing. People who still use plain Make are most likely doing so on legacy projects that can not adopt modules in the near future in any case. Thus it would seem that the most probable ways C++ modules are going to be used are a) VS projects b) whatever Xcode ends up implementing c) Ninja files. [1] https://isocpp.org/files/papers/CppDevSurvey-2023-summary.pdf [2] https://cmake.org/cmake/help/latest/manual/cmake-cxxmodules.7.html
[Bug c++/119848] New: Concept check makes it impossible to return types that depend on the type being defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119848
Bug ID: 119848
Summary: Concept check makes it impossible to return types that
depend on the type being defined
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jpakkane at gmail dot com
Target Milestone: ---
This might not be a bug in GCC itself, but in the C++ specification. The
behaviour is the same for Clang and MSVC. Still, this seems like a thing that a
developer might reasonably expect to work.
## Description
Assume that we have a non-templated string type called MyString and a template
container class MyVector. The string class provides a split function.
Thus the relevant pieces of code would be like this:
class MyString {
...
MyVector split() const;
};
This works fine. Now let's assume that MyVector has requirements on the types
it stores, for example that it can be noexcept-moved. If you specify them as
`static_assert`s in the MyVector class everything still works.
However if you specify them as a concept, then things fail. Assuming the
concept is named `WellBehaved` the output is:
:30:5: error: constraints not satisfied for class template 'MyVector'
[with T = MyString]
30 | MyVector split();
| ^~~
:13:10: note: because 'MyString' does not satisfy 'WellBehaved'
13 | template
However if you specify the return value as `auto` like this:
auto split() const { /* implementation here */ }
things work again.
## Full source code
https://gcc.godbolt.org/z/YjxWGdKbr
---
#include
template
concept WellBehaved = requires(T a, T b, const T &c, T &&d) {
requires noexcept(a = b);
requires noexcept(a = std::move(b));
requires noexcept(T{});
requires noexcept(T{b});
requires noexcept(T{c});
requires noexcept(T{d});
};
template
struct Holder {
T foo;
};
struct Failing {
Failing() noexcept;
Failing(Failing &&o) noexcept;
Failing(const Failing &o) noexcept ;
Failing& operator=(Failing &&o) noexcept;
Failing& operator=(const Failing &o) noexcept ;
// The following line leads to
// a compile error because "Failing" is not
// fully defined yet.
//
// If you comment it out, everything compiles.
Holder return_my_own_type_wrapped();
// If the return type is deduced, things work.
auto return_my_own_type_wrapped_deduced() {
return Holder { *this };
};
};
Holder instantiation;
