<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Feb 19, 2015 at 4:02 AM, Benjamin Kramer <span dir="ltr"><<a href="mailto:benny.kra@gmail.com" target="_blank">benny.kra@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">> On 19.02.2015, at 03:07, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>
><br>
> On Mon, Feb 16, 2015 at 3:08 AM, Benjamin Kramer <<a href="mailto:benny.kra@googlemail.com">benny.kra@googlemail.com</a>> wrote:<br>
> Author: d0k<br>
> Date: Mon Feb 16 05:08:00 2015<br>
> New Revision: 229374<br>
><br>
> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=229374&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=229374&view=rev</a><br>
> Log:<br>
> ASTMatchers: Replace enable_if with static_assert.<br>
><br>
> This is nicer in general and gives a better error message, but it also might<br>
> bring MSVC 2013 back to life.<br>
><br>
> Modified:<br>
>     cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h<br>
><br>
> Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h<br>
> URL: <a href="http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h?rev=229374&r1=229373&r2=229374&view=diff" target="_blank">http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h?rev=229374&r1=229373&r2=229374&view=diff</a><br>
> ==============================================================================<br>
> --- cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h (original)<br>
> +++ cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h Mon Feb 16 05:08:00 2015<br>
> @@ -1178,14 +1178,10 @@ template <unsigned MinCount, unsigned Ma<br>
>  struct VariadicOperatorMatcherFunc {<br>
>    DynTypedMatcher::VariadicOperator Op;<br>
><br>
> -  template <unsigned Count, typename T><br>
> -  struct EnableIfValidArity<br>
> -      : public std::enable_if<MinCount <= Count && Count <= MaxCount, T> {};<br>
> -<br>
>    template <typename... Ms><br>
> -  typename EnableIfValidArity<sizeof...(Ms),<br>
> -                              VariadicOperatorMatcher<Ms...>>::type<br>
> -  operator()(Ms &&... Ps) const {<br>
> +  VariadicOperatorMatcher<Ms...> operator()(Ms &&... Ps) const {<br>
><br>
> Why the space after the '...'? That seems to be in conflict with the usual LLVM style.<br>
<br>
</div></div>Lacking precedent in LLVM I let clang-format decide how to format this piece of code. If LLVM's style prefers to leave out the space we should fix clang-format first ;)</blockquote><div><br></div><div>Yes, I strongly believe this is a clang-format bug. The ellipsis binds even tighter to the right than * and & do; it makes no sense to put a space after it for bind-to-the-right formatting. To drive the point home, consider this:</div><div><br></div><div>  template<typename T> void f(int *...fp(T))</div><div><br></div><div>This is a pack of functions each of which returns 'int *'. That is, the ... binds closest, then the (T), then the *. It is highly misleading to format that as</div><div><br></div><div>  template<typename T> void f(int *... fp(T))<br></div><div><br></div><div>... especially since we'd put the * closer than that if the ... were absent. (I think the space should go to the left of the ... even in styles that normally put the space on the right, but I don't think I'm likely to win that argument.)</div></div></div></div>