Strange case of "Redundant boolean literal in conditional return statement"

Hello everyone!

Today I was working at a comparison operator when I noticed Resharper highlighting the entire function block content. After looking into it; I can not figure out:

  1. Why it takes issue with this particular piece of code.
  2. How the proposed solution would do anything other than ruin my code.

Therefore, I would like some feedback from you. I suspect it's a bug; but maybe I am missing something. Below are three images; first is my comparison operator function with the warning message:

 

Here is an image showing the proposed solution:

 

Here is an image showing the result of that proposed solution:


Any feedback is appreciated!

7 comments
Comment actions Permalink

Hello,

It might be a bug in clang-tidy (looks somewhat similar to https://bugs.llvm.org/show_bug.cgi?id=38240), but to file it in the clang-tidy issue tracker an isolated snippet of code which shows the problem would be necessary. Would it be possible to create one?

0
Comment actions Permalink

Hello Igor!

I made a snippet; it's right here.

Is that what you were looking for?

0
Comment actions Permalink

Thanks Maurits.

This code doesn't compile though (since a vector can't hold references) - I guess invalid code might trigger some bugs in clang-tidy.

Do you see this check only on non-compilable code?

1
Comment actions Permalink

You are correct that vectors should not accept references because the component type of containers like vectors must be re-assignable and references are not re-assignable. However, this code does actually compile just fine (on Visual Studio 2019). You are also correct that the bug only manifests itself when using references in a vector.

Thank you for pointing out my mistake. We do have new issues now to ponder over though:

  1. Should this be contributed to the clang tidy project as a bug even though this code should never exist?
  2. Should some tool not warn the user against using references as a container?
  3. If the answer to the second question is yes; then what project should contribute this feedback to?
0
Comment actions Permalink

This can't be right, the code does not compile - have you included the header into any .cpp file? Here's the error on godbolt - https://gcc.godbolt.org/z/KBcT1h. Re your questions:

1. I've filed https://bugs.llvm.org/show_bug.cgi?id=42529, but I wouldn't expect it to get high priority. Linter tools like clang-tidy are usually expected to run on valid code.

2. Clang-tidy does print an error (from the clang compiler), but clang-tidy errors are disabled by default in R++ and the location of the error is in a system header, so it isn't shown anyway. We might be able to fix clang-tidy integration so that an error like this is shown in the opened file.

0
Comment actions Permalink

Good call on not including the header into any source file. This was indeed my mistake; sorry for the resulting confusion.

  1. Sounds good. Thanks for doing that!
  2. It throws a whole slew of errors now that I have included it in a source file. To be honest; they might be confusing to someone who doesn't know that references are not allowed as container objects. But errors being unhelpful has got more to do with the MSVC compiler I believe. The Clang compiler seems to throw much more clear errors generally. Your suggestion might therefore be a good addition indeed.

Regardless of what you guys end up doing; thanks for the help and patience Igor. You were very helpful!

0
Comment actions Permalink

Thank you, do let us know if you have any other feedback!

0

Please sign in to leave a comment.