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

            Bug ID: 127275
           Summary: Confusing error recovery when splicing the null
                    reflection as a CTP type
           Product: gcc
           Version: 16.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: programmer00001h at gmail dot com
  Target Milestone: ---

```
namespace mynmsp{
    using info = decltype(^^::);
}
template<typename[:mynmsp::info{}:] access_context>
struct Confusing{};
```

causes `g++ -std=c++26 -freflection magic.cpp` to complain:

magic.cpp:4:34: error: cannot splice a null reflection
    4 | template<typename[:mynmsp::info{}:] access_context>
      |                                  ^~
magic.cpp:4:34: error: expected a reflection of a type
magic.cpp:4:10: error: ‘mynmsp::access_context’ has not been declared
    4 | template<typename[:mynmsp::info{}:] access_context>
      |          ^~~~~~~~

The first two errors are expected, but the third one isn't. Furthermore...

```
namespace mynmsp{
    using info = decltype(^^::);
    using T = bool;
}
template<typename[:mynmsp::info{}:] T>
struct Confusing{};

consteval{
    Confusing<3> _;
}
```

yields

magic.cpp:5:34: error: cannot splice a null reflection
    5 | template<typename[:mynmsp::info{}:] T>
      |                                  ^~
magic.cpp:5:34: error: expected a reflection of a type
magic.cpp: In static member function ‘<lambda()> static’:
magic.cpp:9:16: error: narrowing conversion of ‘3’ from ‘int’ to ‘bool’
[-Wnarrowing]
    9 |     Confusing<3> _;
      |                ^

note how `mynmsp::T` is used as the CTP's type, i.e. error recovery treated the
struct declaration as
```
template<mynmsp::T>
struct Confusing{};
```

This is, well, very Confusing and likely unintended.

Note that `mynmsp::` may be any other namespace; for example, if we
#include<meta> and then name the `info` type as `std::meta::info`, then it'll
try to look up the CTP name in `std::meta`. Or the name could be unqualified:
If `info` was a global typedef, then `template<typename[:info{}:] name>` would
look up `name` in the global namespace.


My system's GCC info just in case:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/16/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure
--enable-languages=ada,c,c++,d,fortran,go,lto,m2,objc,obj-c++,rust,cobol
--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-gcc-major-version-only
--with-linker-hash-style=gnu --with-system-zlib --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-fixincludes --disable-libssp
--disable-libstdcxx-pch --disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 16.2.1 20260810 (GCC)

Reply via email to