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

Reply via email to