Re: [lmi] [PATCH] More clang [[noreturn]] changes

[Greg Chicares]

On 2017-04-14 17:13, Vadim Zeitlin wrote:
> 
>  Sorry for not submitting both of them together with the other changes
> before, but it turns out there are more instances of the same "[[noreturn]]
> used in function definition and not declaration" problem, so here are two
> more patches fixing them and allowing me to fully build lmi with clang.

Both committed and pushed.

>  The first patch should be uncontroversial as it just moves the attribute
> from the function definition to its declaration. The only possible problem
> here is that I'm not sure how is this code supposed to be formatted with
> lmi conventions.

I really have no idea. They keep adding more and more verbose things to the
language, and I've tended to treat them like 'static' and place them first;
or, actually, more like 'template' and write them on a separate line...and
sometimes even with verbose conditionals:

template<typename To, typename From>
#if 201402L < __cplusplus
constexpr
#endif // 201402L < __cplusplus
inline To bourn_cast(From from, std::false_type, std::false_type)

If we need an overload that just throws an exception, I'm not sure where I'd
write "[[noreturn]]"...or whether that attribute can even be combined with
constexpr. I guess we'll just improvise until experience suggests a reasonable
practice for all these new "declarators" or whatever they're called.

Maybe we should skip gcc-5 and upgrade to gcc-6.2.1 because that's what
debian-9 offers. Then the conditional above would be unnecessary, and I
wouldn't have to wonder why I can't compile code that I write using
std::bool_constant (because it's C++17). But probably we should first
build everything routinely with clang.

>  The second one is potentially more problematic, as it just removes the use
> of the attribute with the value_cast<> template specializations, meaning
> that gcc will now give warnings about possibly missing "noreturn" here with
> -Wsuggest-attribute=noreturn. However I hope we can live with these
> warnings (not resulting in errors, of course, as this flag is not used by
> default), while we definitely can't live with clang errors, if we want to
> use this compiler. The only other solution I can see is adding a
> NORETURN_IF_NOT_CLANG macro with the obvious meaning, but I don't think
> it's worth doing this just to avoid the -Wsuggest-attribute=noreturn
> warning. But please let me know if you disagree.

I completely agree. 'gcc -Wsuggest-attribute=noreturn' gives many false
positives, as we had already seen before; it's worth running occasionally,
but it's never an error to omit "[[noreturn]]"--yet it's always an error
to write it incorrectly. It's always good to use more than one compiler
because it helps catch problems like this; I used to use comeau C++ for
that reason, but now I guess clang is the natural choice.