Page MenuHomePhabricator

[clang-tidy] Change google-explicit-constructor to ignore conversions and operators marked `explicit(false)`
Needs ReviewPublic

Authored by njames93 on Jan 18 2022, 11:37 AM.

Details

Summary

These explicit(cond) feature in c++20 can be used to specify if a declaration should be implicit or explicit.
For these cases we shouldn't produce any warning as the developer is already enforcing a specific behaviour.

Fixes https://llvm.org/PR53115.

Diff Detail

Event Timeline

njames93 created this revision.Jan 18 2022, 11:37 AM
njames93 requested review of this revision.Jan 18 2022, 11:37 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 18 2022, 11:37 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript

Hmmm, this is a rule for checking a specific style guide. https://google.github.io/styleguide/cppguide.html#Implicit_Conversions doesn't say that explicit(false) is a reasonable marking. In fact, it says "Implicit conversions can sometimes be necessary and appropriate for types that are designed to be interchangeable, for example when objects of two types are just different representations of the same underlying value. In that case, contact your project leads to request a waiver of this rule."

So I think this behavior needs to be behind a flag so that the default behavior continues to match what the style guide requires (or the style guide should be updated to clarify the behavior of explicit(false)).

Hmmm, this is a rule for checking a specific style guide. https://google.github.io/styleguide/cppguide.html#Implicit_Conversions doesn't say that explicit(false) is a reasonable marking. In fact, it says "Implicit conversions can sometimes be necessary and appropriate for types that are designed to be interchangeable, for example when objects of two types are just different representations of the same underlying value. In that case, contact your project leads to request a waiver of this rule."

So I think this behavior needs to be behind a flag so that the default behavior continues to match what the style guide requires (or the style guide should be updated to clarify the behavior of explicit(false)).

My understanding of the rule(as a non Googler) was that explicit(false) is an effective way to disable the rule by explicitly declaring the constructor to be implicit. Which is much cleaner than throwing NOLINT markers about.
In any case this c++20 syntax is not supported as the current fixit produces invalid code, as evidenced in the initial bug report.

Hmmm, this is a rule for checking a specific style guide. https://google.github.io/styleguide/cppguide.html#Implicit_Conversions doesn't say that explicit(false) is a reasonable marking. In fact, it says "Implicit conversions can sometimes be necessary and appropriate for types that are designed to be interchangeable, for example when objects of two types are just different representations of the same underlying value. In that case, contact your project leads to request a waiver of this rule."

So I think this behavior needs to be behind a flag so that the default behavior continues to match what the style guide requires (or the style guide should be updated to clarify the behavior of explicit(false)).

My understanding of the rule(as a non Googler) was that explicit(false) is an effective way to disable the rule by explicitly declaring the constructor to be implicit. Which is much cleaner than throwing NOLINT markers about.

FWIW, I agree that this would be a reasonable exception to the rule and makes for cleaner code than NOLINT comments. I'm pointing out that the rule text doesn't say that exceptions are something they want to silence diagnostics for. The way I read the guideline suggests that they don't consider the diagnostic a false positive.

In any case this c++20 syntax is not supported as the current fixit produces invalid code, as evidenced in the initial bug report.

Agreed that issue needs to be fixed.