-
Notifications
You must be signed in to change notification settings - Fork 13.6k
[Clang] constexpr variables wrongfully treated as captures in certain lambdas #120503
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I initially ran into this problem when my code had With Yuxuan's reduced code, I just tried to reproduce the initial "wrong branch being taken" behavior, and got a different manifestation of this bug: #include <type_traits>
template <typename...>
struct tag_t {};
template <auto...>
struct vtag_t {};
template <auto... V>
inline constexpr vtag_t<V...> vtag{};
template <typename T>
constexpr bool alt = true;
template <typename = void>
auto branch_on_alt() {
return []<typename T>(tag_t<T>) {
return vtag<[]() {
if constexpr (alt<T>) {
return vtag<1>;
} else {
return vtag<0>;
}
}()>;
}(tag_t<int>{});
}
static_assert(std::is_same_v<
decltype(branch_on_alt()), vtag_t<vtag<1>>>); Again, the error (see https://godbolt.org/z/e364M1v9T) does not reproduce on gcc or MSVC. But maybe the new message has some additional hint for why this is happening?
So, rather than "the wrong branch is taken", it seems like clang is attempting to compile both Edit: Yes, lifting the inner lambda to a function works around the issue: template <typename T>
constexpr auto lifted_lambda() {
if constexpr (alt<T>) {
return vtag<1>;
} else {
return vtag<0>;
}
}
template <typename = void>
auto branch_on_alt() {
return []<typename T>(tag_t<T>) {
return vtag<lifted_lambda<T>()>;
}(tag_t<int>{});
} |
CC @cor3ntin |
The common thread for the issues is that there's a lambda defined inside a template argument list, I think. |
Uh oh!
There was an error while loading. Please reload this page.
Clang currently rejects the following program by saying "error: variable 'XXXcap' cannot be implicitly captured in a lambda with no capture-default specified"
This seems wrong. As
XXXcap
here is not a capture. GCC and MSVC seem to have no problem with this.See compiler explorer: https://godbolt.org/z/7rqcfGe7x
The text was updated successfully, but these errors were encountered: