r210295 - Remove old proposal notices

[Richard Smith]

On Wed, Feb 4, 2015 at 6:38 PM, John McCall <rjmccall at apple.com> wrote:

> > On Jun 5, 2014, at 4:17 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> > On Thu, Jun 5, 2014 at 3:11 PM, Alp Toker <alp at nuanti.com> wrote:
> > Author: alp
> > Date: Thu Jun  5 17:11:20 2014
> > New Revision: 210295
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=210295&view=rev
> > Log:
> > Remove old proposal notices
> >
> > Let's just go ahead and assume the answer was 'I do'
> >
> > :)
> >
> > You can check what proposals have made it into the ABI here:
> >
> >   http://mentorembedded.github.io/cxx-abi/abi.html
> >
> > For the ones that aren't in the ABI, having a comment explaining why
> we're using them and where they come from is useful. None of these three
> are in the ABI document yet; please back this out for now.
> >
> > John: any chance we could get the ABI document updated with these? (
> http://sourcerytools.com/pipermail/cxx-abi-dev/2012-January/000024.html)
>
> After much delay, added.  We don’t seem to get this right, though, at
> least not when the destination type isn’t dependent:
>
> template <class T, class U> T fst(T, U);
> struct A {
>   int x[3];
> };
> template <class T> decltype(fst(A{1,2},T())) foo(T t) {}
>
> int main() {
>   foo(1);
> }
>
> We produce:
>   _Z3fooIiEDTcl3fstcv1AililLi1ELi2EEEcvT__EEES1_
> It should be:
>   _Z3fooIiEDTcl3fsttl1ALi1ELi2EcvT__EEES1_
>

There are quite a few bugs conspiring to give that result :( Our AST is
also poorly-suited to this mangling, because the braces are not considered
to be part of the functional cast itself; they're part of its subexpression.

If you parenthesize the argument to A:
>   template <class T> decltype(fst(A({1,2}),T())) foo(T t) {}
> We produce:
>   _Z3fooIiEDTcl3fstcv1AcvS0_ililLi1ELi2EEEcvT__EEES1_
> It should be:
>   _Z3fooIiEDTcl3fstcv1AliLi1ELi2EcvT__EEES1_
>

Somewhat related, we also get this wrong:

struct X { X(int); };
int f(X);
template<typename T> void f(decltype(f(0), T())) { f(0); }
void g() { f<int>(0); }

... because we explicitly mangle the implicit conversion from int to X. I
see

_Z1fIiEvDTcmcl1fLi0EEcvT__EE from EDG
_Z1fIiEvDTcmclL_Z1f1XELi0EEcvT__EE from GCC
_Z1fIiEvDTcmclL_Z1f1XEcvS0_cvS0_Li0EEcvT__EE from Clang

I think GCC and Clang are right to use the resolved name L_Z1f1XE rather
than the unresolved name 1f here, and GCC's mangling is right overall. Do
you agree?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150204/39d33094/attachment.html>