r210295 - Remove old proposal notices

[John McCall]

> On Feb 4, 2015, at 9:36 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> On Wed, Feb 4, 2015 at 6:38 PM, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote:
> On Jun 5, 2014, at 4:17 PM, Richard Smith <richard at metafoo.co.uk <mailto:richard at metafoo.co.uk>> wrote:
> > John: any chance we could get the ABI document updated with these? (http://sourcerytools.com/pipermail/cxx-abi-dev/2012-January/000024.html <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

Ugh, that’s awful.

> 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?


> As an aside: if we have a fully-resolved call in an instantiation-dependent expression, should we really be putting any used default arguments into the mangling?

I feel like both of these points need to be asked on the cxx-abi-dev.  I definitely don’t think we should be mangling default arguments, but I’m not sure that resolving ‘f’ here is really consistent with the general dictate to follow the syntactic tree.

> All of the above fixed in r228274. I'm not really very happy with our AST representation here; we've overloaded CXXConstructExpr to mean too many different syntactic things that it's hard to reconstruct the right mangling.

The rule used to be that a “bare" CXXConstructExpr — neither a specific subclass nor the implementation of a cast — was always implicit, and that there were subclasses which provided additional syntactic information.  I think it would make sense to have a dedicated subclass for the truly implicit case as well.  The implicit case is always a constructor conversion or copy-construction, right?

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150204/a4c329de/attachment.html>