[clang] False-positive with -Wswitch-default and templates

[al42and]

Compiling the following code with Clang trunk and -Wswitch-default option produces "'switch' missing 'default' label" warning, despite the label clearly being there:

template<typename Index>
int f1(Index i)
{
    switch (i)
    {
        case 0: return 0;
        case 1: return 1;
        default: return 2;
    }
}

$ clang++ -fsyntax-only -Wswitch-default test.cpp 
test.cpp:4:5: warning: 'switch' missing 'default' label [-Wswitch-default]
    4 |     switch (i)
      |     ^
1 warning generated.

$ clang++ --version
clang version 18.0.0git (https://github.com/llvm/llvm-project.git c0d2ea9d4202c7cce4214b3057a709ff2f1128ae)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/aland/llvm-project/build/install//bin

Godbolt: https://godbolt.org/z/c3a695b5n

Related to #73077

[shafik]

CC @dongjianqiang2

[aaronpuchert]

I think the problem is the loop condition SC && !HasDependentValue. We also don't emit an error on duplicate default labels, which should violate [stmt.switch]p3:

template<typename Index>
int f1(Index i)
{
    switch (i)
    {
        case 0: return 0;
        case 1: return 1;
        default: return 2;
        default: return 3;
    }
}

For what it's worth, GCC and MSVC also don't produce an error here. It's also rather strange code: if the type that we switch on is a template parameter, how can the values be fixed?

[hstk30-hw]

https://godbolt.org/z/j99z57efY
Template warning when it's instanced.
I fix it in #76007

[al42and]

It's also rather strange code: if the type that we switch on is a template parameter, how can the values be fixed?

In the original code, this function is used exclusively with integral types. They are assumed to have a limited range of values, but can be either int or size_t, and we wanted to avoid any spurious type conversions. This is likely unnecessary, since all the relevant code is in the same translation unit and the optimizer can see through, but it was done while dealing with a GPU register allocator issue, and I was too lazy to also check how well integer widening/narrowing would be handled here; and that's how this code came to be. But I think such pattern can have other uses (also limited to integral types), e.g., returning known values for small inputs and falling back to default: return slow_function<T>(x); otherwise, so the code snippet should not be totally nonsensical.

[hstk30-hw]

Fix it in #76007 .
So close it :)