Clang compile error related to static_assert and boost::hana
Asked Answered
T

1

5

Consider the following problem which compiles successfully on Clang 3.8 using -std=c++14.

#include <boost/hana.hpp>

namespace hana = boost::hana;

int main() {
    constexpr auto indices = hana::range<unsigned, 0, 3>();
    hana::for_each(indices, [&](auto i) {
        hana::for_each(indices, [&](auto j) {
            constexpr bool test = (i == (j == i ? j : i));
            static_assert(test, "error");
        });
    });
}

The test is quite non-sensical but that is not the point. Consider now an alternative version where the test is directly put inside the static_assert:

#include <boost/hana.hpp>

namespace hana = boost::hana;

int main() {
    constexpr auto indices = hana::range<unsigned, 0, 3>();
    hana::for_each(indices, [&](auto i) {
        hana::for_each(indices, [&](auto j) {
            static_assert((i == (j == i ? j : i)), "error");
        });
    });
}

Now I get a bunch of compile errors, saying

error: reference to local variable i declared in enclosing lambda expression

Question: What causes the second version to fail?

Edit: Could this be a compiler bug? I turns out that when accessing i before the static_assert, everything compiles again:

#include <boost/hana.hpp>

namespace hana = boost::hana;

int main() {
    constexpr auto indices = hana::range<unsigned, 0, 3>();
    hana::for_each(indices, [&](auto i) {
        hana::for_each(indices, [&](auto j) {
            constexpr auto a = i;
            static_assert((i == (j == i ? j : i)), "error");
        });
    });
}

Update: The same behaviour can be reproduced on Clang 4.0 and the current development branch 5.0.

Update 2: As suggested by @LouisDionne, I filed this as a bug: https://bugs.llvm.org/show_bug.cgi?id=33318.

Trackman answered 4/6, 2017 at 15:31 Comment(5)
@aschepler: Sorry - I don't get your point. Would you mind elaborating?Trackman
"this" is similar #43666110Searles
I believe that is a compiler bug. I think your best bet is to file a bug against Clang and see what the knowledgeable folks over there think.Farmyard
@LouisDionne - thanks for the suggestion. It got acknowledged as a bug in Clang.Trackman
Can you please post a link to the bug in an answer to your own question so it can be marked as answered?Farmyard
T
1

This is a bug in the Clang compiler and was acknowledged as such. Here is the link to it: https://bugs.llvm.org/show_bug.cgi?id=33318.

Trackman answered 6/6, 2017 at 17:37 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.