Trouble with MSVC again

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Trouble with MSVC again

Olaf Krzikalla
Hi @clang,

just now I stumbled over a MSVC issue which I first considered being a
reincarnation of a bug we've discussed here about a year ago (Jun/26/2009).
The troublesome lines are in Action.h:127

    FullExprArg &operator=(const FullExprArg& Other) {
      Expr = ExprArg(move(const_cast<FullExprArg&>(Other).Expr));
      return *this;
    }


(Doug should know them from last weekend.)
However after digging somewhat deeper I'm rather puzzled. Apparently
DISABLE_SMART_POINTERS is not defined on my system. However, then
ExprArg is an ASTOwningResult and the move result gets constructed to an
ASTOwningResult. The strange part: the operator= of ASTOwningResult is
really private, so MSVC is blatantly right by complaining.
I thought removing the "ExprArg" cast would help, but if you look at
Ownership.h:797 then you'll notice that move returns not an
ASTResultMover but an ASTOwningResult. Thats even more strange. Am I the
only one with !defined(DISABLE_SMART_POINTERS) == true? (I made the last
update about two weeks ago and it worked fine then). Or is there
something broken in my build configuration and DISABLE_SMART_POINTERS
should be defined? In any case I can't imagine how any compiler can
build clang without a defined DISABLE_SMART_POINTERS.
Any ideas?

Best regards
Olaf Krzikalla


PS: my solution is as follows:

template <ASTDestroyer Destroyer> inline
moving::ASTResultMover<Destroyer> hack_move(ASTOwningResult<Destroyer>
&ptr) {
  return moving::ASTResultMover<Destroyer>(ptr);
}

and

FullExprArg &operator=(const FullExprArg& Other) {
   Expr = hack_move(const_cast<FullExprArg&>(Other).Expr);
   return *this;
}


I have the sneaking suspicion that hack_move actually is the correct
move implementation.


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Trouble with MSVC again

Dimitry Andric
On 2010-05-10 17:09, Olaf Krzikalla wrote:
> just now I stumbled over a MSVC issue which I first considered being a
> reincarnation of a bug we've discussed here about a year ago (Jun/26/2009).
> The troublesome lines are in Action.h:127
>
>     FullExprArg &operator=(const FullExprArg& Other) {
>       Expr = ExprArg(move(const_cast<FullExprArg&>(Other).Expr));
>       return *this;
>     }

I kludged around this using:

Index: tools/clang/include/clang/Parse/Action.h
===================================================================
--- tools/clang/include/clang/Parse/Action.h (revision 103401)
+++ tools/clang/include/clang/Parse/Action.h (working copy)
@@ -114,7 +114,7 @@ class Action : public ActionBase {
       : Expr(move(const_cast<FullExprArg&>(Other).Expr)) {}
 
     FullExprArg &operator=(const FullExprArg& Other) {
-      Expr = ExprArg(move(const_cast<FullExprArg&>(Other).Expr));
+      Expr.operator=(move(const_cast<FullExprArg&>(Other).Expr));
       return *this;
     }
 

which MSVC does accept.


> (Doug should know them from last weekend.)
> However after digging somewhat deeper I'm rather puzzled. Apparently
> DISABLE_SMART_POINTERS is not defined on my system. However, then
> ExprArg is an ASTOwningResult and the move result gets constructed to an
> ASTOwningResult. The strange part: the operator= of ASTOwningResult is
> really private, so MSVC is blatantly right by complaining.
> I thought removing the "ExprArg" cast would help, but if you look at
> Ownership.h:797 then you'll notice that move returns not an
> ASTResultMover but an ASTOwningResult. Thats even more strange. Am I the
> only one with !defined(DISABLE_SMART_POINTERS) == true?

No.  In my case, DISABLE_SMART_POINTERS is also undefined, at least
according to the IntelliSense stuff.

I guess it is supposed to call:

ASTOwningResult &operator=(moving::ASTResultMover<Destroyer> mover)

but MSVC isn't smart enough to figure this out on its own?
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Trouble with MSVC again

Douglas Gregor

On May 10, 2010, at 9:19 AM, Dimitry Andric wrote:

> On 2010-05-10 17:09, Olaf Krzikalla wrote:
>> just now I stumbled over a MSVC issue which I first considered being a
>> reincarnation of a bug we've discussed here about a year ago (Jun/26/2009).
>> The troublesome lines are in Action.h:127
>>
>>    FullExprArg &operator=(const FullExprArg& Other) {
>>      Expr = ExprArg(move(const_cast<FullExprArg&>(Other).Expr));
>>      return *this;
>>    }
>
> I kludged around this using:
>
> Index: tools/clang/include/clang/Parse/Action.h
> ===================================================================
> --- tools/clang/include/clang/Parse/Action.h (revision 103401)
> +++ tools/clang/include/clang/Parse/Action.h (working copy)
> @@ -114,7 +114,7 @@ class Action : public ActionBase {
>       : Expr(move(const_cast<FullExprArg&>(Other).Expr)) {}
>
>     FullExprArg &operator=(const FullExprArg& Other) {
> -      Expr = ExprArg(move(const_cast<FullExprArg&>(Other).Expr));
> +      Expr.operator=(move(const_cast<FullExprArg&>(Other).Expr));
>       return *this;
>     }
>
>
> which MSVC does accept.

I just committed this fix. Sorry for the breakage!

        - Doug


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev