search for: true_type

...(working copy) @@ -1187,10 +1187,15 @@ #endif // _LIBCPP_HAS_NO_VARIADICS +template <class _Fst, class _Snd> +struct __select_2nd { + typedef _Snd type; +}; + // is_assignable template <class _Tp, class _Arg> -decltype((_VSTD::declval<_Tp>() = _VSTD::declval<_Arg>(), true_type())) +typename __select_2nd<decltype(_VSTD::declval<_Tp>() = _VSTD::declval<_Arg>()), true_type>::type #ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES __is_assignable_test(_Tp&&, _Arg&&); #else @@ -1209,7 +1214,7 @@ struct __is_assignable_imp : public common_type...

...> (...)/sysroot-x86_64-linux-gnu/usr/include/c++/v1/cstddef:110: > > (...)/sysroot-x86_64-linux-gnu/usr/include/c++/v1/type_traits:740:56: > error: _Float16 is not supported on this target > template <> struct __libcpp_is_floating_point<_Float16> : > public true_type {}; > This is quite odd, because libc++ trunk has no mentions of `_Float16`, and I see none here: https://llvm.org/svn/llvm-project/libcxx/branches/release_80/include/type_traits -- Marshall -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm...

..._LIBCPP_HAS_NO_VARIADICS > > +template <class _Fst, class _Snd> > +struct __select_2nd { > + typedef _Snd type; > +}; > + > // is_assignable > > template <class _Tp, class _Arg> > -decltype((_VSTD::declval<_Tp>() = _VSTD::declval<_Arg>(), true_type())) > +typename __select_2nd<decltype(_VSTD::declval<_Tp>() = _VSTD::declval<_Arg>()), true_type>::type > #ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES > __is_assignable_test(_Tp&&, _Arg&&); > #else > @@ -1209,7 +1214,7 @@ > struct __is_assignable_...

On Sep 28, 2012, at 5:54 PM, Richard Smith <richard at metafoo.co.uk> wrote: > Reduced testcase: > > template<typename T> struct A { typedef decltype(T() + 0) type; }; > template<typename T> struct B { > struct C { typedef typename A<C*>::type type; }; > typedef typename A<C*>::type type; > }; > B<int> b; > > ... produces ...

...::iterator it; > > ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~ > > /usr/bin/../lib/c++/v1/type_traits:1184:57: note: in instantiation of > > member class 'Templ8<int>::Member' requested here > > decltype((_VSTD::declval<_Tp>() = _VSTD::declval<_Arg>(), true_type())) > > ^ > > /usr/bin/../lib/c++/v1/type_traits:1186:1: note: while substituting > > deduced template arguments into function template > > '__is_assignable_test' [with _Tp = Templ8<int>::Member *&, _Ar...

...iations). I'm not at all clear on whether that is permissible behavior for a standard library implementation, but it still seems to be a problem in some cases. libc++'s is_assignable implementation uses SFINAE on this: decltype((_VSTD::declval<_Tp>() = _VSTD::declval<_Arg>(), true_type())) Now, our case was: _Tp = Member*&, _Arg = Member*. In that case, we use the built-in assignment operator, which produces an lvalue of type Member*. Then we perform argument-dependent lookup looking for an overloaded 'operator,', because its RHS is of a class type. This lookup trigg...

Dear testers, 8.0.0-rc2 has been tagged from the release_80 branch at r353413. Please run the test script, share your results, and upload binaries. I'll get the source tarballs and docs published as soon as possible, and binaries as they become available. Thanks, Hans

...; typename map<K,Member*>::iterator it; ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~ /usr/bin/../lib/c++/v1/type_traits:1184:57: note: in instantiation of member class 'Templ8<int>::Member' requested here decltype((_VSTD::declval<_Tp>() = _VSTD::declval<_Arg>(), true_type())) ^ /usr/bin/../lib/c++/v1/type_traits:1186:1: note: while substituting deduced template arguments into function template '__is_assignable_test' [with _Tp = Templ8<int>::Member *&, _Arg = <no value>] __is_assignable_t...

...gt;> > ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~ >> > /usr/bin/../lib/c++/v1/type_traits:1184:57: note: in instantiation of >> > member class 'Templ8<int>::Member' requested here >> > decltype((_VSTD::declval<_Tp>() = _VSTD::declval<_Arg>(), true_type())) >> > ^ >> > /usr/bin/../lib/c++/v1/type_traits:1186:1: note: while substituting >> > deduced template arguments into function template >> > '__is_assignable_test' [with _Tp = Templ8<int>::Me...

...map<K,Member*>::iterator it; > ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~ > /usr/bin/../lib/c++/v1/type_traits:1184:57: note: in instantiation of > member class 'Templ8<int>::Member' requested here > decltype((_VSTD::declval<_Tp>() = _VSTD::declval<_Arg>(), true_type())) > ^ > /usr/bin/../lib/c++/v1/type_traits:1186:1: note: while substituting > deduced template arguments into function template > '__is_assignable_test' [with _Tp = Templ8<int>::Member *&, _Arg = <no > valu...

Don Hinton via llvm-dev <llvm-dev at lists.llvm.org> writes: > Used like this: isa<T,1>(v) or isa<T, true>(v) I don't think I would know what that means when I see it in code. -David > On Sat, Apr 6, 2019 at 9:45 AM Mehdi AMINI via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Fri, Apr 5, 2019 at 5:15 AM Aaron Ballman via

Hi, I've just tagged LLVM 7.1.0-final. Testers, please upload the final binaries. Thanks, Tom

...<map> Sort. + // Helper for test code to print hash codes. + void PrintTo(const hash_code &code, ::std::ostream *os) { What's with the extra leading :: before std::? + namespace hashing { namespace detail { + template <> struct is_hashable_data<LargeTestInteger> : true_type {}; + } } // End hashing detail namespace. +} // End LLVM namespace. A reminder about 1 namespace-per-line, but also the comments on ending namespaces are odd. They usually look like "} // end namespace llvm" or "} // namespace llvm", and I prefer the latter. Nick On 29 Feb...

...t;T, true>(v) >> >> I don't think I would know what that means when I see it in code. >> > > Sorry, I was just trying to highlight a different way of doing it, and > lazily used a bool. Here's something a little more realistic: > > struct NulCheck : std::true_type {}; > > template <class X, class Check, class Y, > typename std::enable_if<Check::value, X>::type * = nullptr> > LLVM_NODISCARD inline bool isa(const Y *Val) { > return Val && isa<X>(Val); > } > > isa<foo,NulCheck>(v) > > Not...

tl;dr If there are no objections I'd like to change clang-format's LLVM style to always put `template <...>` on its own line. I think it's a general code-layout consistency win and avoids some cases where trivial code changes result in significant formatting differences (see the last example). Examples of the current behavior: -------------- template <class ELFT> class

Thanks for the feedback thus far! I've updated the header file, and enclosed a complete patch against LLVM. This passes all the regtests, and I'll be doing more thorough testing of LLVM itself with the patch. I've included some basic unit tests, but could probably do more here... Not sure it's worth delaying the initial submission though, as the best testing is to use a hash

Hello folks, TL;DR: This is my proposed hashing interface based on a proposed standard hashing interface. It also is implemented with a much faster and higher quality algorithm than the current one. This is an *early draft* of the code, looking for initial feedback. There has been recent interest in improving the quality and consistency of LLVM's approach to hashing. In particular, getting