https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117215

            Bug ID: 117215
           Summary: The preprocessor may fail to replace #include
                    statements under certain conditions.
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: preprocessor
          Assignee: unassigned at gcc dot gnu.org
          Reporter: 1300296933 at qq dot com
  Target Milestone: ---

Created attachment 59388
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59388&action=edit
This attachment can be used to reproduce a bug by simply executing make

I am confident that the inclusion of my header files is correct (verified with
Clang and MSVC). However, GCC sometimes expands #include to nothing, preventing
various symbols from being imported. For example:
```cpp
//xxx.h
#define NS_BEGIN namespace test{
#define NS_END }

NS_BEGIN
int hello();
NS_END

//main.cpp
#include <xxx.h>

NS_BEGIN

void include_fail()
{
    ::test::hello();
}

NS_END
```
Below is the possible errors:
```shell
main.cpp:2:1: error: 'NS_BEGIN' does not name a type
main.cpp:6:1: error: 'hello' is not a member of 'test'; did you mean...
```
The output in the attachment looks like this:
```shell
nagisa/include/nagisa/type_trait/././detail/modifier.h:5:1: error:
'NGS_BUILD_LIB_DETAIL_BEGIN' does not name a type
    5 | NGS_BUILD_LIB_DETAIL_BEGIN
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~
nagisa/include/nagisa/type_trait/././detail/modifier.h:5:1: note: the macro
'NGS_BUILD_LIB_DETAIL_BEGIN' had not yet been defined
In file included from nagisa/include/nagisa/build_lib/construct.h:11,
                 from nagisa/include/nagisa/type_trait/././environment.h:6,
                 from nagisa/include/nagisa/type_trait/./core.h:4:
nagisa/include/nagisa/build_lib/./details/detail.h:5:9: note: it was later
defined here
    5 | #define NGS_BUILD_LIB_DETAIL_BEGIN NGS_BUILD_LIB_BEGIN namespace
details {
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~
nagisa/include/nagisa/type_trait/././detail/modifier.h:24:23: error:
'add_const_like_t' does not name a type; did you mean 'add_pointer_like_t'?
   24 | using add_cv_like_t = add_const_like_t<add_volatile_like_t<T,
Modifier>, Modifier>;
      |                       ^~~~~~~~~~~~~~~~
      |                       add_pointer_like_t
nagisa/include/nagisa/type_trait/././detail/modifier.h:27:47: error:
'add_cv_like_t' was not declared in this scope
   27 | using add_cvref_like_t = add_reference_like_t<add_cv_like_t<T,
Modifier>, Modifier>;
      |                                               ^~~~~~~~~~~~~
nagisa/include/nagisa/type_trait/././detail/modifier.h:27:72: error: template
argument 1 is invalid
   27 | using add_cvref_like_t = add_reference_like_t<add_cv_like_t<T,
Modifier>, Modifier>;
      |                                                                       
^
nagisa/include/nagisa/type_trait/././detail/modifier.h:29:1: error:
'NGS_BUILD_LIB_DETAIL_END' does not name a type
   29 | NGS_BUILD_LIB_DETAIL_END
      | ^~~~~~~~~~~~~~~~~~~~~~~~
nagisa/include/nagisa/type_trait/././detail/modifier.h:29:1: note: the macro
'NGS_BUILD_LIB_DETAIL_END' had not yet been defined
nagisa/include/nagisa/build_lib/./details/detail.h:6:9: note: it was later
defined here
    6 | #define NGS_BUILD_LIB_DETAIL_END } NGS_BUILD_LIB_END
      |         ^~~~~~~~~~~~~~~~~~~~~~~~
nagisa/include/nagisa/type_trait/./core.h:8:7: error: 'details' has not been
declared
    8 | using details::add_const_like_t;
...
```

This bug is particularly strange, as the output changes unpredictably, even
with minor modifications like adding comments. For example:

```cpp
#include <xxx>

#include <nagisa/build_lib/destruct.h>
```
Changing to:
```cpp
#include <xxx>
//
#include <nagisa/build_lib/destruct.h>
```
Simply adding a harmless comment alters GCC's error output.

Due to this instability, I couldn't remove some extra files from the
attachments, as doing so changes GCC's behavior. The attached files are not
complex, so I kindly ask for your review.

Please refer to the Makefile for usage instructions, or you can directly
execute make to observe the output.

This was tried on my windows, on wsl, and on my friend's arch linux

Test Environment:
OS: Windows 11; WSL2 (Kernel: 5.15.153.1, Release: Arch Linux, Arch: x86_64)
GCC Versions: 13.2.0; 14.1; 15.0.0

Below is the output from gcc -v:
```shell
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/nagisa/toolchains/x86_64-pc-linux-gnu/x86_64-pc-linux-gnu/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/nagisa/toolchains_build/gcc/configure --disable-werror
--disable-multilib --enable-languages=c,c++ --disable-bootstrap --enable-nls
--prefix=/home/nagisa/toolchains/x86_64-pc-linux-gnu/x86_64-pc-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20240922 (experimental) (GCC)
```

```shell
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=ada,c,c++,d,fortran,go,lto,m2,objc,obj-c++,rust
--enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/issues
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.2.1 20240910 (GCC)
```

```shell
Using built-in specs.
COLLECT_GCC=C:\workspace\develop\sdk\espressif\tools\xtensa-esp-elf\esp-13.2.0_20240530\xtensa-esp-elf\bin\xtensa-esp-elf-gcc.exe
COLLECT_LTO_WRAPPER=C:/workspace/develop/sdk/espressif/tools/xtensa-esp-elf/esp-13.2.0_20240530/xtensa-esp-elf/bin/../libexec/gcc/xtensa-esp-elf/13.2.0/lto-wrapper.exe
Target: xtensa-esp-elf
Configured with:
/builds/idf/crosstool-NG/.build/HOST-x86_64-w64-mingw32/xtensa-esp-elf/src/gcc/configure
--build=x86_64-build_pc-linux-gnu --host=x86_64-host_w64-mingw32
--target=xtensa-esp-elf --prefix=/builds/idf/crosstool-NG/builds/xtensa-esp-elf
--exec_prefix=/builds/idf/crosstool-NG/builds/xtensa-esp-elf
--with-local-prefix=/builds/idf/crosstool-NG/builds/xtensa-esp-elf/xtensa-esp-elf
--with-sysroot=/builds/idf/crosstool-NG/builds/xtensa-esp-elf/xtensa-esp-elf
--with-native-system-header-dir=/include --with-newlib --enable-threads=no
--disable-shared --with-pkgversion='crosstool-NG esp-13.2.0_20240530'
--disable-__cxa_atexit --enable-cxx-flags=-ffunction-sections --disable-libgomp
--disable-libmudflap --disable-libmpx --disable-libssp --disable-libquadmath
--disable-libquadmath-support --disable-libstdcxx-verbose
--with-gmp=/builds/idf/crosstool-NG/.build/HOST-x86_64-w64-mingw32/xtensa-esp-elf/buildtools/complibs-host
--with-mpfr=/builds/idf/crosstool-NG/.build/HOST-x86_64-w64-mingw32/xtensa-esp-elf/buildtools/complibs-host
--with-mpc=/builds/idf/crosstool-NG/.build/HOST-x86_64-w64-mingw32/xtensa-esp-elf/buildtools/complibs-host
--with-isl=/builds/idf/crosstool-NG/.build/HOST-x86_64-w64-mingw32/xtensa-esp-elf/buildtools/complibs-host
--enable-lto --enable-target-optspace --without-long-double-128 --disable-nls
--enable-multiarch --enable-languages=c,c++ --disable-libstdcxx-verbose
--enable-threads=posix --enable-gcov-custom-rtio --enable-libstdcxx-time=yes
--with-gnu-ld
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.0 (crosstool-NG esp-13.2.0_20240530)
```

Reply via email to