[cfe-dev] Allow implicit copy constructor between address spaces in C++

[Richard Smith]

On Sun, May 18, 2014 at 10:49 PM, John McCall <rjmccall at apple.com> wrote:

> On May 18, 2014, at 4:43 PM, Adam Strzelecki <ono at java.pl> wrote:
>
> The simplest solution here is probably to add a special case to the
> type-checker which permits an address-space mismatch when directly calling
> a trivial copy constructor or copy-assignment operator.
>
>
> I have submitted patch that works reasonably well without need to extra
> attributes or builtins.
>
>
> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140512/105706.html
>
> The idea behind was to enforce implicit conversion which drops address
> space qualifier if copy constructor fails and destination is POD without
> user defined copy constructor.
>
>
> Hmm.  I’d like Richard’s opinion about where to do this.  There are a lot
> of compile-time benefits to only changing the failure path during
> initialization, but I’m a little worried about having these exact
> conditions.  Maybe the best thing to do is to just try again with an
> OpaqueValueExpr in the default address space and, if that succeeds and
> picks a trivial constructor, then you can go ahead and generate the C-style
> AST.
>

I think the most general thing to do would be to teach SemaInit that a
reference can bind to an object with a different address space if the
initialized entity is the first parameter of a trivial copy or move
constructor or assignment, and to teach it to add a new
cross-address-space-copy step when that happens.

Separately, overload resolution should be taught that this is possible; the
first standard conversion sequence in such a case should probably have
conversion rank.

+        const RecordType *DestRecordType = DestType->getAs<RecordType>();
> +        CXXRecordDecl *DestRecordDecl
> +          = cast<CXXRecordDecl>(DestRecordType->getDecl());
>
> This is just DestType->getAsCXXRecordDecl().
>
> John.
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140522/c262bfb5/attachment.html>