On Wed, Nov 16, 2022 at 01:45:19PM +0000, Jonathan Wakely wrote: > > On Mon, 14 Nov 2022 at 13:57, Jakub Jelinek <ja...@redhat.com> wrote: > > > >> Hi! > >> > >> As filed by Jonathan in the PR, I've screwed up the requires syntax > >> in the extended floating point specialization: > >> - requires(__complex_type<_Tp>::type) > >> + requires requires { typename __complex_type<_Tp>::type; } > >> and doing this change resulted in lots of errors because > >> __complex_whatever > >> overfloads from extended floating point types were declared after the > >> templates which used them. > >> > >> The following patch fixes that. > >> > >> Bootstrapped/regtested on x86_64-linux and i686-linux, additionally > >> I've tested that with _GLIBCXX_HAVE_FLOAT128_MATH not being defined > >> while __STDCPP_FLOAT128_T__ defined one can still use > >> std::complex<std::float128_t> for basic arithmetic etc., just one can't > >> expect std::sin etc. to work in that case (because we don't have any > >> implementation). > >> > >> Ok for trunk? > >> > > > > OK, thanks for the quick fix. > > > > Oh, also no released version of Clang can handle the C++20 rules about > 'typename' yet, so we get this error: > > complex:1843:15: error: no template named 'type' in '__complex_ty > pe<_Tp>'; did you mean 'ctype'? > typedef std::__complex_type<_Tp>::type _ComplexT; > ^~~~~~~~~~~~~~~~~~~~~~~~~~ > It needs a 'typename' after 'typedef'. > > I can add that if you want though.
Can you? Sorry, I have already committed the patch before noticing your mail. Jakub