Quantcast

Re: [llvm-dev] Spurious cast warning for C++?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] Spurious cast warning for C++?

Brian Cain via cfe-dev
This is question is probably better on the clang  cfe-dev list. 

On Sun, Apr 9, 2017 at 12:01 PM Brennan Vincent via llvm-dev <[hidden email]> wrote:
How difficult would it be to add a warning to Clang when the programmer
performs a cast that provably has no effect?

A particular case I have in mind is someone getting confused and calling
std::move on an argument to a copy-constructor for a class that doesn't
implement move semantics.

I would be grateful if someone either (1) told me why this is
difficult/impossible, or (2) gave me some pointers to where I could
start trying to implement it...
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
--
~Craig

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] Spurious cast warning for C++?

Brian Cain via cfe-dev
What does "have no effect" mean in this case? In my mind, there are many casts that have no effect - other than allowing the code to compile, which is quite an important effect in itself (e.g. casting a 32-bit unsigned to a pointer on your typical 32-bit system).

Are you seeking to warn for:

   int a;
   int b;

   a = (int) b;

and similar things?

--
Mats

On 9 April 2017 at 20:35, Craig Topper via llvm-dev <[hidden email]> wrote:
This is question is probably better on the clang  cfe-dev list. 

On Sun, Apr 9, 2017 at 12:01 PM Brennan Vincent via llvm-dev <[hidden email]> wrote:
How difficult would it be to add a warning to Clang when the programmer
performs a cast that provably has no effect?

A particular case I have in mind is someone getting confused and calling
std::move on an argument to a copy-constructor for a class that doesn't
implement move semantics.

I would be grateful if someone either (1) told me why this is
difficult/impossible, or (2) gave me some pointers to where I could
start trying to implement it...
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
--
~Craig

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] Spurious cast warning for C++?

Brian Cain via cfe-dev
-llvm-dev

Actually, maybe "spurious cast" is too broad and ambitious. Maybe it's better to focus specifically on std::move.

The only thing I am really interested in is stuff like

class A {
public:
    A &operator=(const A &a) {
        // do some copy ...
        return *this;
    }
}

int f() {
    A a;
    A b;
    b = std::move(a);
}

, which can be a source of unforeseen performance bugs (e.g., people think they are moving big vectors but really copying them)

On Mon, Apr 10, 2017, at 02:39 AM, mats petersson wrote:
What does "have no effect" mean in this case? In my mind, there are many casts that have no effect - other than allowing the code to compile, which is quite an important effect in itself (e.g. casting a 32-bit unsigned to a pointer on your typical 32-bit system).
Are you seeking to warn for:
   int a;
   int b;
   a = (int) b;
and similar things?

--
Mats

On 9 April 2017 at 20:35, Craig Topper via llvm-dev <[hidden email]> wrote:
This is question is probably better on the clang  cfe-dev list. 

On Sun, Apr 9, 2017 at 12:01 PM Brennan Vincent via llvm-dev <[hidden email]> wrote:
How difficult would it be to add a warning to Clang when the programmer
performs a cast that provably has no effect?

A particular case I have in mind is someone getting confused and calling
std::move on an argument to a copy-constructor for a class that doesn't
implement move semantics.

I would be grateful if someone either (1) told me why this is
difficult/impossible, or (2) gave me some pointers to where I could
start trying to implement it...
_______________________________________________
LLVM Developers mailing list

--
~Craig

_______________________________________________
LLVM Developers mailing list



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] Spurious cast warning for C++?

Brian Cain via cfe-dev
In reply to this post by Brian Cain via cfe-dev
On Sun, Apr 9, 2017 at 12:35 PM, Craig Topper via cfe-dev <[hidden email]> wrote:
This is question is probably better on the clang  cfe-dev list. 

On Sun, Apr 9, 2017 at 12:01 PM Brennan Vincent via llvm-dev <[hidden email]> wrote:
How difficult would it be to add a warning to Clang when the programmer
performs a cast that provably has no effect?

A particular case I have in mind is someone getting confused and calling
std::move on an argument to a copy-constructor for a class that doesn't
implement move semantics.

I would be grateful if someone either (1) told me why this is
difficult/impossible, or (2) gave me some pointers to where I could
start trying to implement it...

clang-tidy has related diagnostics, such as those listed at https://clang.llvm.org/extra/clang-tidy/checks/misc-move-const-arg.html

Not all of them are desirable, IMO, but clang-tidy (rather than clang-the-compiler) is the right place for them.

-- James 

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Loading...