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!

Comment actions Permalink


It might be a bug in clang-tidy (looks somewhat similar to, 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?

Comment actions Permalink

Hello Igor!

I made a snippet; it's right here.

Is that what you were looking for?

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?

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?
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 - Re your questions:

1. I've filed, 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.

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!

Comment actions Permalink

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


Please sign in to leave a comment.