[clang-tidy] Improving narrowing conversions

[gchatelet]

Summary

Newly flagged narrowing conversions:

• integer to narrower signed integer (this is compiler implementation defined),
• integer - floating point narrowing conversions,
• floating point - integer narrowing conversions,
• constants with narrowing conversions (even in ternary operator).

[gchatelet]

In D53488#1274205, @JonasToth wrote:

Did you run this code over a real-world code-base and did you find new stuff and/or false positives or the like?

Yes I did run it over our code base. I didn't find false positive but 98% of the warnings are from large generated lookup table initializers, e.g. const static float kTable[] = {0.0, 2.0, ... };
Since every number in the list triggers the warning, it accounts for most of them.

I scrutinized a few hundreds of the rest: none were actual bugs (although it's hard to tell sometimes), most are legit like float value = 0.0; but I also found some oddities from generated headers.

To me the warnings are useful and if it were my code I'd be willing to fix them. That said, I'd totally understand that many people would find them useless or annoying.
What do you think? Shall we still commit this as is?

[hokein]

In D53488#1275750, @gchatelet wrote:

In D53488#1274205, @JonasToth wrote:

Did you run this code over a real-world code-base and did you find new stuff and/or false positives or the like?

Yes I did run it over our code base. I didn't find false positive but 98% of the warnings are from large generated lookup table initializers, e.g. const static float kTable[] = {0.0, 2.0, ... };
Since every number in the list triggers the warning, it accounts for most of them.

I scrutinized a few hundreds of the rest: none were actual bugs (although it's hard to tell sometimes), most are legit like float value = 0.0; but I also found some oddities from generated headers.

To me the warnings are useful and if it were my code I'd be willing to fix them. That said, I'd totally understand that many people would find them useless or annoying.
What do you think? Shall we still commit this as is?

It would be nice to know how many new findings does this patch introduce (number of findings before the patch vs after). If it is not too much, it is fine the commit as it is.
I'd suggest to run the check on llvm code repository (using clang-tidy/tool/run-clang-tidy.py, and only enable cppcoreguidelines-narrowing-conversions).

[gchatelet]

In D53488#1275786, @hokein wrote:

In D53488#1275750, @gchatelet wrote:

In D53488#1274205, @JonasToth wrote:

Did you run this code over a real-world code-base and did you find new stuff and/or false positives or the like?

Yes I did run it over our code base. I didn't find false positive but 98% of the warnings are from large generated lookup table initializers, e.g. const static float kTable[] = {0.0, 2.0, ... };
Since every number in the list triggers the warning, it accounts for most of them.

I scrutinized a few hundreds of the rest: none were actual bugs (although it's hard to tell sometimes), most are legit like float value = 0.0; but I also found some oddities from generated headers.

To me the warnings are useful and if it were my code I'd be willing to fix them. That said, I'd totally understand that many people would find them useless or annoying.
What do you think? Shall we still commit this as is?

It would be nice to know how many new findings does this patch introduce (number of findings before the patch vs after). If it is not too much, it is fine the commit as it is.
I'd suggest to run the check on llvm code repository (using clang-tidy/tool/run-clang-tidy.py, and only enable cppcoreguidelines-narrowing-conversions).

I'll get back with some numbers.

In the meantime I found this one which is interesting
https://github.com/intel/ipmctl/blob/master/src/os/efi_shim/lnx_efi_api.c#L45
spec.tv_nsec (which is signed long) is converted to double and back to int64. There surely can be some loss in the process since double can only express 2^52 integers (2^52ns is about 52 days)

[JonasToth]

That one looks interesting :)

Am 25.10.18 um 17:13 schrieb Guillaume Chatelet via Phabricator:

gchatelet added a comment.

In https://reviews.llvm.org/D53488#1275786, @hokein wrote:

In https://reviews.llvm.org/D53488#1275750, @gchatelet wrote:

In https://reviews.llvm.org/D53488#1274205, @JonasToth wrote:

Did you run this code over a real-world code-base and did you find new stuff and/or false positives or the like?

Yes I did run it over our code base. I didn't find false positive but 98% of the warnings are from large generated lookup table initializers, e.g. const static float kTable[] = {0.0, 2.0, ... };
Since every number in the list triggers the warning, it accounts for most of them.

I scrutinized a few hundreds of the rest: none were actual bugs (although it's hard to tell sometimes), most are legit like float value = 0.0; but I also found some oddities https://github.com/ARM-software/astc-encoder/blob/master/Source/vectypes.h#L13999 from generated headers.

To me the warnings are useful and if it were my code I'd be willing to fix them. That said, I'd totally understand that many people would find them useless or annoying.
What do you think? Shall we still commit this as is?

It would be nice to know how many new findings does this patch introduce (number of findings before the patch vs after). If it is not too much, it is fine the commit as it is.
I'd suggest to run the check on llvm code repository (using clang-tidy/tool/run-clang-tidy.py, and only enable cppcoreguidelines-narrowing-conversions).

I'll get back with some numbers.

In the meantime I found this one which is interesting
https://github.com/intel/ipmctl/blob/master/src/os/efi_shim/lnx_efi_api.c#L45
spec.tv_nsec (which is signed long) is converted to double and back to int64. There surely can be some loss in the process since double can only express 2^52 integers (2^52ns is about 52 days)

Repository:

rCTE Clang Tools Extra

https://reviews.llvm.org/D53488

[gchatelet]

• Add more checks, disable bool implicit casts warning, enable ternary operator warnings.

[gchatelet]

So I've updated the code to add more narrowing conversions.
It now tests constant expressions against receiving type, do not warn about implicit bool casting, handles ternary operator with constant expressions.

I ran it on our code base: results look legit.
I'll ping back here with numbers for llvm once I figured out how to build the database the tool is complaining about :)

[gchatelet]

So I ran llvm/tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py
The version with all checks produces 65664 unique findings.
The version restricted to cppcoreguidelines-narrowing-conversions produces 4323 unique findings. That's about +7% of findings.
I can post some random ones if you're interested.

[JonasToth]

because this now diverged quite a bit i will revert the lgtm for now and take a longer look at the new patch.
The numbers you reported sound good.

clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp

28

This matcher seems no to be used, did I overlook sth?

docs/ReleaseNotes.rst

77 ↗

(On Diff #171692)

that seems to be unrelated

[JonasToth]

docs/ReleaseNotes.rst

77 ↗

(On Diff #171692)

sry for noise, this was part of the history diffs!

[Szelethus]

clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp

13

Is APInt used anywhere?

[gchatelet]

• Remove leftover

[gchatelet]

Here are 15 random ones from llvm synced at 8f9fb8bab2e9b5b27fe40d700d2abe967b99fbb5.

lib/Target/ARM/AsmParser/ARMAsmParser.cpp:3802:31: warning: narrowing conversion from 'int' to 'unsigned int' [cppcoreguidelines-narrowing-conversions]
tools/dsymutil/MachOUtils.cpp:330:10: warning: narrowing conversion from 'unsigned long' to 'unsigned int' [cppcoreguidelines-narrowing-conversions]
lib/Target/X86/X86ISelDAGToDAG.cpp:1237:14: warning: narrowing conversion from 'int' to 'unsigned int' [cppcoreguidelines-narrowing-conversions]
tools/llvm-objdump/MachODump.cpp:7998:12: warning: narrowing conversion from 'int' to 'unsigned int' [cppcoreguidelines-narrowing-conversions]
lib/CodeGen/MachinePipeliner.cpp:3268:11: warning: narrowing conversion from 'int' to 'unsigned int' [cppcoreguidelines-narrowing-conversions]
lib/CodeGen/MIRParser/MIRParser.cpp:823:41: warning: narrowing conversion from 'int' to 'unsigned int' [cppcoreguidelines-narrowing-conversions]
lib/Analysis/MemoryBuiltins.cpp:610:59: warning: narrowing conversion from 'int' to 'unsigned int' [cppcoreguidelines-narrowing-conversions]
lib/Analysis/ValueTracking.cpp:2291:21: warning: narrowing conversion from 'unsigned long' to 'unsigned int' [cppcoreguidelines-narrowing-conversions]
lib/Target/ARM/ARMLoadStoreOptimizer.cpp:1470:43: warning: narrowing conversion from 'int' to 'unsigned int' [cppcoreguidelines-narrowing-conversions]
lib/Target/AArch64/AArch64ISelDAGToDAG.cpp:2300:14: warning: narrowing conversion from 'int' to 'unsigned int' [cppcoreguidelines-narrowing-conversions]
lib/Target/X86/X86TargetTransformInfo.cpp:2590:27: warning: narrowing conversion from 'int' to 'unsigned int' [cppcoreguidelines-narrowing-conversions]
lib/Target/ARM/ARMFrameLowering.cpp:1770:27: warning: narrowing conversion from 'int' to 'unsigned int' [cppcoreguidelines-narrowing-conversions]
lib/Target/ARM/ARMConstantIslandPass.cpp:514:22: warning: narrowing conversion from 'int' to 'unsigned int' [cppcoreguidelines-narrowing-conversions]
lib/Transforms/Vectorize/LoopVectorize.cpp:5500:13: warning: narrowing conversion from 'int' to 'unsigned int' [cppcoreguidelines-narrowing-conversions]
lib/Target/AArch64/AsmParser/AArch64AsmParser.cpp:1199:54: warning: narrowing conversion from 'int' to 'unsigned int' [cppcoreguidelines-narrowing-conversions]

clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp

13

Good catch thx.

28

It's a leftover indeed thx for noticing.

[JonasToth]

clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp

20

I think this comment is now outdated.

38

Here and in the matcher below:

isInTemplateInstantiation is a wide range, if you match only on isTypeDependent() it would remove the false negatives from templates but still catch clear cases that are within a template function.

With the current implementation non-type-templates would be ignored as well.
IMHO that could be done in a follow-up to keep the scope on one thing.

75

Please enclose that struct with an anonymous namespace

94

please remove that const as its uncommon to qualify values in LLVM code.

101

Maybe repleace One with 1.0? It sounds slightly weird with the following Ones

127

what about value dependentness? That is resolveable, but i believe ignored here

134

narrowing to bool is not nice either. I would prefer diagnosing these too.

141

please no const and auto as well, as the type is not obvious.

156

please no const

158

you can shorten this condition with isDependentType

164

please no const

174

you could remove both temporaries and return directly and then ellide the braces.
If you don't like that please remove the const

docs/clang-tidy/checks/cppcoreguidelines-narrowing-conversions.rst

15 ↗

(On Diff #171692)

Please reword that slightly. The narrowing conversions are defined by the standard, we just implement it "partially" or so.

test/clang-tidy/cppcoreguidelines-narrowing-conversions.cpp

79

llvm doesn't add a name to the TODOs.

The necessity to use the correct literal might still be there even if the number is in range: the precisions differ. I believe it could have differences on non-integer values what literal you use respectively.

101

could you please add tests with integer arithmetic?

E.g. this:

short n1, n2;
float result = n1 + n2; // 'n1 + n2' is of type 'int' because of integer rules

[gchatelet]

• Address comments

[gchatelet]

clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp

38

Sounds good, let's fix this in a follow-up patch.

101

It's a leftover, I've reworded and changed the code as well.

158

I tried using the following but it crashes when I run clang tidy other our codebase:

if (LhsType->isDependentType() || RhsType->isDependentType())
    return false;

Maybe I misunderstood what you suggested?

174

I have to keep both variables or the first one might shortcircuit the second that goes undetected.
e.g. unsigned char c = b ? 1 : -1;

[JonasToth]

clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp

158

You understood correct, but I was wrong. Could you please try LhsType->isInstantiationDependentType(), as this should involve all kind of template surprises.

174

Indeed, no problem.

[courbet]

clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp

136

I think it would be clearer to have something like "narrowing conversion from %0 literal to %1"

test/clang-tidy/cppcoreguidelines-narrowing-conversions.cpp

162

I think some people would not like to be warned on this (especially for the form if (!returns_int()), because the ! does the cast). What about adding options to the check to disable some forms ?

163

What about providing a fix for this one :
while (i != 0) {

[lebedev.ri]

test/clang-tidy/cppcoreguidelines-narrowing-conversions.cpp

163

Is this actually a narrowing conversion as per the CPPCG?
Conversion to bool is a special case, it's not a truncation, but a x != 0.
I'd think cases like these where bool was pretty clearly meant (if(), while(), for(), ???) should be exempt.

[JonasToth]

test/clang-tidy/cppcoreguidelines-narrowing-conversions.cpp

163

No it is not an narrowing conversion the CPPCG are concerned: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es46-avoid-lossy-narrowing-truncating-arithmetic-conversions

Short:

ES.46: Avoid lossy (narrowing, truncating) arithmetic conversions

Enforcement

A good analyzer can detect all narrowing conversions. However, flagging all narrowing conversions will lead to a lot of false positives. Suggestions:

    - flag all floating-point to integer conversions (maybe only float->char and double->int. Here be dragons! we need data)
    - flag all long->char (I suspect int->char is very common. Here be dragons! we need data)
    - consider narrowing conversions for function arguments especially suspect

We do have a readability-check that is concerned about int -> bool conversions. Because of that I think we could safely ignore the int->bool conversion.
But float -> bool is still suspicious in my opinion. It has the same semantics, but comparing float on equality is dangerous and one could argue it shall be enforced through point 1 (all float-to-int conversions).

[gchatelet]

test/clang-tidy/cppcoreguidelines-narrowing-conversions.cpp

163

@JonasToth Do you have the name of the readability check so I can document the behavior?

[JonasToth]

test/clang-tidy/cppcoreguidelines-narrowing-conversions.cpp

163

Should be https://clang.llvm.org/extra/clang-tidy/checks/readability-implicit-bool-conversion.html

[gchatelet]

• Addressing comments and enhancing diagnostics

[JonasToth]

I think the check is really close.
If the other reviewers want to take a look at it again, now is a good moment :)

clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp

110

Nit: Please move these two comment above the if and make s/conversion/Conversion/.

186

I am surprised by following modulo 2 arithmetic and think it's a bit misleading. Writing just module arithmetic is probably better, as module 2 somewhat implies there a only 2 valid values (0, 1).

Is this the int -> unsigned int case path? That seems worth diagnosing too.

[gchatelet]

• Addressing comments

clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp

186

Yes, thx for noticing. I updated the comment, I think it's better now.

Indeed this is the int -> unsigned int case path. Warning here would lead to a lot of noise for everybody doing bitwise operations since -1 is a compact way to represent the maximum value. Since the semantic is valid and well defined by the standard I'm unsure it's worth the pain. I'm open to suggestions though.

Maybe a good way to figure out is what would be the correct fix for say unsigned long AllBits = -1;

[gchatelet]

Is this good enough to go? @JonasToth

[aaron.ballman]

clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp

16

Is this include needed?

68

Is there a case where you expect the QualType to be invalid? If not, drop the OrNull bit.

77–78

Spurious parens.

82

Spurious parens.

94

Then T should be passed in as a reference type instead of using this assertion.

96

Assert the above condition and unconditionally return.

98–100

Debugging code. Assert above and unilaterally return.

117

Perhaps a better approach is to assert this is true and then unilaterally return.

121–122

This seems like debugging code that should be removed.

141

Please rename the identifier to not conflict with a type name.

183–184

Spurious parens.

[JonasToth]

clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp

186

Comment is fine :)

I though that we have check that diagnoses unsigned i = -1; but I don't find it right now (maybe its still in review or so, i belive it was related to introducing std::numeric_limits<>).
As its well defined and not narrowing and not mentionend by the CPPCG in that section its ok, maybe worth an option in the future?

[gchatelet]

• Addressing comments, adding Option to disable FP to FP narrowing warnings, handling FP literals.

[aaron.ballman]

clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp

111–116

This can be further simplified into:

assert(T.isInteger() && "Unexpected builtin type");
return {llvm::APSInt::getMinValue(Context.getTypeSize(&T), T.isUnsignedInteger()),
         llvm::APSInt::getMaxValue(Context.getTypeSize(&T), T.isUnsignedInteger())};

192

shortciruit -> short circuit

[gchatelet]

• Address comments + fix hex values display

[gchatelet]

clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp

186

An Option to warn on these sound like a good idea.
I added TODOs.

[JonasToth]

Only a few nits from me.

[JonasToth]

clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp

24

I would make this on by default. It is a valid diagnostic and people using this check might be surprised they have to activate it.

86

i think llvm_unreachable would fit better.

172

s/clang tidy already/clang-tidy check already/ (not sure if clang-tidy-check is correcter from english point of view.)

179

Why is the return here true even without diagnostic?

224

llvm_unreachable

[gchatelet]

• Address comments

[gchatelet]

clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp

179

Good catch

[gchatelet]

• Remove debugging leftover

[JonasToth]

So, finally LGTM :)
Please give @aaron.ballman a chance to comment, as he reviewed too.

Thanks for your patch!

[gchatelet]

In D53488#1296940, @JonasToth wrote:

So, finally LGTM :)
Please give @aaron.ballman a chance to comment, as he reviewed too.

Thanks for your patch!

Thank you for bearing with me.
Waiting for input from @aaron.ballman

[aaron.ballman]

test/clang-tidy/cppcoreguidelines-narrowing-conversions.cpp

79–81

This is not a narrowing conversion -- there should be no diagnostic here. See [dcl.init.list]p7.

99

Missing tests involving literals, which are not narrowing conversions. e.g., float f = 1ULL; should not diagnose.

174

This is only true on architectures where char is defined to be signed char rather than unsigned char.

188

This is only narrowing if sizeof(int) < sizeof(long) which is not the case on all architectures.

211

Whatttt? How does one narrow from an unsigned 32-bit number to a signed 64-bit number?

228

This may be narrowing on an implementation that defines char to be unsigned.

232

This may be fine on implementations that define char to be unsigned.

[gchatelet]

• State char signess clearly

[gchatelet]

Thx for the review. I have two suggestions in the comments let me know what you think.

test/clang-tidy/cppcoreguidelines-narrowing-conversions.cpp

79–81

Thx for pointing this out.
I would like to keep the diagnostic (without mentioning the narrowing) because there is no reason to write 2.0 instead of 2.0f. WDYT?

99

This is handled on l.262

174

This is taken care of. The test fails when adding -funsigned-char.
The current test is executed with -target x86_64-unknown-linux which should imply -fsigned-char. Anyways, I'll add -fsigned-char to make sure this is obvious.

188

Yes this is taken care of in the code, the size of the type must be smaller.
It works here because the test runs with -target x86_64-unknown-linux

211

unsigned long is unsigned 64-bit so it does not fit in signed 64-bit.
https://godbolt.org/z/VnmG0s

228

Same as previous comments. Would it make sense to create a different test with -funsigned-char to check these behaviors?

232

ditto

[aaron.ballman]

test/clang-tidy/cppcoreguidelines-narrowing-conversions.cpp

79–81

I see no reason to warn on a literal value that isn't changed as a result of the notional narrowing. The standard clearly defines the behavior, so I think that would be needlessly chatty.

99

Ah, I missed that, thank you!

174

Ah, thank you! Can you also pass -funsigned-char to test the behavior is as expected?

188

Please add a test for another target where this is not the case.

211

unsigned long is not 64-bit on all targets, and that should be tested. https://godbolt.org/z/VQx-Yy

[gchatelet]

• Addressed comments

[gchatelet]

test/clang-tidy/cppcoreguidelines-narrowing-conversions.cpp

79–81

Done. Plus added som tests.

[aaron.ballman]

test/clang-tidy/cppcoreguidelines-narrowing-conversions-long-is-32bits.cpp

4–10 ↗

(On Diff #174374)

Add some static_asserts for these bit sizes?

test/clang-tidy/cppcoreguidelines-narrowing-conversions.cpp

42–44

I don't think these should diagnose. They're both harmless as the literal values are exactly representable in the destination type.

[gchatelet]

• Refactored the code to make it simpler, added more tests

[gchatelet]

test/clang-tidy/cppcoreguidelines-narrowing-conversions.cpp

42–44

Yes indeed they are harmless but why not write the correct literal in the first place?
I'm keeping these warnings for now. Let me know if you feel strongly about it.

[gchatelet]

• Reverting the WarnOnFloatingPointNarrowingConversion option to be on by default

[aaron.ballman]

test/clang-tidy/cppcoreguidelines-narrowing-conversions.cpp

42–44

Yes indeed they are harmless but why not write the correct literal in the first place?

Why force the user to modify their code when the behavior will be exactly the same as before?

I'm keeping these warnings for now. Let me know if you feel strongly about it.

I don't feel very strongly on this case, but it seems needlessly chatty to me to diagnose code that's not incorrect. For instance, this code could exist in a (system) header file that the user doesn't have the ability to correct.

[gchatelet]

• Added a new option warn about wrong type literals

[gchatelet]

test/clang-tidy/cppcoreguidelines-narrowing-conversions.cpp

42–44

I've added a WarnOnCastingLiterals option to display them.
It's on by default.
Let me know if you have a better name, I'm not super happy with it.
Let me know if you think it should be off by default.

[aaron.ballman]

clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp

25

I think the concept here is more broad than the option name suggests -- this is really a "pedantic mode" for this feature, because there is a notional narrowing but no semantic difference. I would name the option PedanticMode and have it off-by-default, personally.

104

What variables are created here?

105

short ciruit -> short-circuit

129

integer -> integers

244–246

You should cite where this quotation comes from (e.g., [foo.bar]p2)

261–265

Why is this function needed at all?

313–317

Why is this function needed at all?

327

[dcl.init.list]p7.2 instead of a hyperlink.

docs/clang-tidy/checks/cppcoreguidelines-narrowing-conversions.rst

59 ↗

(On Diff #175139)

drop the "so"

61 ↗

(On Diff #175139)

do not -> does not
as such -> and so

62 ↗

(On Diff #175139)

what is the semantic -> what the semantics are

[gchatelet]

• Addressing comments

[gchatelet]

Thank you for bearing with me @aaron.ballman.

clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp

104

Leftover. I rewrote the comment.

261–265

The two empty functions are placeholders so the cases handled by ImplicitCast and BinaryOp are the same.
I'll add some documentation.

313–317

Ditto.

[gchatelet]

• Fixing documentation.

[aaron.ballman]

I think we're almost there -- I had a few outstanding questions about the config options in the tests and making sure we cover all the cases.

test/clang-tidy/cppcoreguidelines-narrowing-conversions-castingliterals-option.cpp

3 ↗

(On Diff #175204)

No need for this setting?

test/clang-tidy/cppcoreguidelines-narrowing-conversions-long-is-32bits.cpp

2–5 ↗

(On Diff #175204)

No need for any of these settings?

test/clang-tidy/cppcoreguidelines-narrowing-conversions-narrowingfloatingpoint-option.cpp

2–5 ↗

(On Diff #175204)

You can drop these lines, I believe, because they match the default values.

test/clang-tidy/cppcoreguidelines-narrowing-conversions-unsigned-char.cpp

2–5 ↗

(On Diff #175204)

No need for these settings?

[gchatelet]

• Removed redundant options in regression tests

[aaron.ballman]

LGTM!

[gchatelet]

In D53488#1307834, @aaron.ballman wrote:

LGTM!

Thx ! \O/

clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp

 //===--- NarrowingConversionsCheck.cpp - clang-tidy------------------------===//
 //
 //                     The LLVM Compiler Infrastructure
 //
 // This file is distributed under the University of Illinois Open Source
 // License. See LICENSE.TXT for details.
 //
 //===----------------------------------------------------------------------===//
 
 #include "NarrowingConversionsCheck.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
 
 using namespace clang::ast_matchers;
 
 namespace clang {
 namespace tidy {
 namespace cppcoreguidelines {
 
 // FIXME: Check double -> float truncation. Pay attention to casts:
 void NarrowingConversionsCheck::registerMatchers(MatchFinder *Finder) {
   // ceil() and floor() are guaranteed to return integers, even though the type
   // is not integral.
   const auto IsCeilFloorCall = callExpr(callee(functionDecl(
       hasAnyName("::ceil", "::std::ceil", "::floor", "::std::floor"))));
 
   const auto IsFloatExpr =
       expr(hasType(realFloatingPointType()), unless(IsCeilFloorCall));
 
-  // casts:
+  // Casts:
   //   i = 0.5;
   //   void f(int); f(0.5);
-  Finder->addMatcher(implicitCastExpr(hasImplicitDestinationType(isInteger()),
-                                      hasSourceExpression(IsFloatExpr),
-                                      unless(hasParent(castExpr())),
-                                      unless(isInTemplateInstantiation()))
-                         .bind("cast"),
-                     this);
+  Finder->addMatcher(
+      implicitCastExpr(
+          anyOf(hasImplicitDestinationType(isInteger()),
+                hasImplicitDestinationType(realFloatingPointType())),
+          hasSourceExpression(IsFloatExpr), unless(hasParent(castExpr())),
 
   // Binary operators:
   //   i += 0.5;
   Finder->addMatcher(
-      binaryOperator(isAssignmentOperator(),
-                     // The `=` case generates an implicit cast which is covered
-                     // by the previous matcher.
-                     unless(hasOperatorName("=")),
-                     hasLHS(hasType(isInteger())), hasRHS(IsFloatExpr),
-                     unless(isInTemplateInstantiation()))
+      binaryOperator(
+          isAssignmentOperator(),
+          hasLHS(anyOf(hasType(isInteger()), hasType(realFloatingPointType()))),
+          hasRHS(IsFloatExpr), unless(isInTemplateInstantiation()))
           .bind("op"),
       this);
 }
 
+static bool IsNarrower(const ASTContext *const Context, const QualType Lhs,
+                       const QualType Rhs) {
+  assert(Lhs->isRealType());     // Either integer or floating point.
+  assert(Rhs->isFloatingType()); // Floating point only.
+  return Lhs->isIntegerType() ||
+         (Context->getTypeSize(Rhs) > Context->getTypeSize(Lhs));
+}
+
 void NarrowingConversionsCheck::check(const MatchFinder::MatchResult &Result) {
-  if (const auto *Op = Result.Nodes.getNodeAs<BinaryOperator>("op")) {
+  const auto &Nodes = Result.Nodes;
+  if (const auto *Op = Nodes.getNodeAs<BinaryOperator>("op")) {
     if (Op->getBeginLoc().isMacroID())
       return;
+    const auto LhsType = Op->getLHS()->getType();
+    const auto RhsType = Op->getRHS()->getType();
+    if (IsNarrower(Result.Context, LhsType, RhsType))
       diag(Op->getOperatorLoc(), "narrowing conversion from %0 to %1")
-        << Op->getRHS()->getType() << Op->getLHS()->getType();
-    return;
-  }
-  const auto *Cast = Result.Nodes.getNodeAs<ImplicitCastExpr>("cast");
+          << RhsType << LhsType;
+  } else if (const auto *Cast = Nodes.getNodeAs<ImplicitCastExpr>("cast")) {
     if (Cast->getBeginLoc().isMacroID())
       return;
+    const auto LhsType = Cast->getType();
+    const auto RhsType = Cast->getSubExpr()->getType();
+    if (IsNarrower(Result.Context, LhsType, RhsType))
       diag(Cast->getExprLoc(), "narrowing conversion from %0 to %1")
-      << Cast->getSubExpr()->getType() << Cast->getType();
+          << RhsType << LhsType;
+  } else {
+    llvm_unreachable("Invalid state");
+  }
 }
 
 } // namespace cppcoreguidelines
 } // namespace tidy
 } // namespace clang

test/clang-tidy/cppcoreguidelines-narrowing-conversions.cpp

 // RUN: %check_clang_tidy %s cppcoreguidelines-narrowing-conversions %t
 
 float ceil(float);
 namespace std {
 double ceil(double);
 long double floor(long double);
 } // namespace std
 
 namespace floats {
 
 struct ConvertsToFloat {
-  operator float() const { return 0.5; }
+  operator float() const { return 0.5f; }
 };
 
-float operator "" _Pa(unsigned long long);
+float operator"" _float(unsigned long long);
 
-void not_ok(double d) {
+void narrow_double_to_int_not_ok(double d) {
   int i = 0;
   i = d;
   // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: narrowing conversion from 'double' to 'int' [cppcoreguidelines-narrowing-conversions]
   i = 0.5f;
   // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: narrowing conversion from 'float' to 'int' [cppcoreguidelines-narrowing-conversions]
   i = static_cast<float>(d);
   // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: narrowing conversion from 'float' to 'int' [cppcoreguidelines-narrowing-conversions]
   i = ConvertsToFloat();
   // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: narrowing conversion from 'float' to 'int' [cppcoreguidelines-narrowing-conversions]
-  i = 15_Pa;
+  i = 15_float;
   // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: narrowing conversion from 'float' to 'int' [cppcoreguidelines-narrowing-conversions]
 }
 
-void not_ok_binary_ops(double d) {
+void narrow_double_to_int_not_ok_binary_ops(double d) {
   int i = 0;
   i += 0.5;
   // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: narrowing conversion from 'double' to 'int' [cppcoreguidelines-narrowing-conversions]
   i += 0.5f;
   // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: narrowing conversion from 'float' to 'int' [cppcoreguidelines-narrowing-conversions]
   i += d;
   // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: narrowing conversion from 'double' to 'int' [cppcoreguidelines-narrowing-conversions]
   // We warn on the following even though it's not dangerous because there is no
   // reason to use a double literal here.
   // TODO(courbet): Provide an automatic fix.
   i += 2.0;
   // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: narrowing conversion from 'double' to 'int' [cppcoreguidelines-narrowing-conversions]
   i += 2.0f;
   // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: narrowing conversion from 'float' to 'int' [cppcoreguidelines-narrowing-conversions]
 
   i *= 0.5f;
   // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: narrowing conversion from 'float' to 'int' [cppcoreguidelines-narrowing-conversions]
   i /= 0.5f;
   // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: narrowing conversion from 'float' to 'int' [cppcoreguidelines-narrowing-conversions]
   i += (double)0.5f;
   // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: narrowing conversion from 'double' to 'int' [cppcoreguidelines-narrowing-conversions]
 }
 
+double operator"" _double(unsigned long long);
+
+float narrow_double_to_float_return() {
+  return 0.5;
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: narrowing conversion from 'double' to 'float' [cppcoreguidelines-narrowing-conversions]
+}
+
+void narrow_double_to_float_not_ok(double d) {
+  float f = 0;
+  f = d;
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: narrowing conversion from 'double' to 'float' [cppcoreguidelines-narrowing-conversions]
+  f = 0.5;
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: narrowing conversion from 'double' to 'float' [cppcoreguidelines-narrowing-conversions]
+  f = 15_double;
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: narrowing conversion from 'double' to 'float' [cppcoreguidelines-narrowing-conversions]
+}
+
+void narrow_double_to_float_not_ok_binary_ops(double d) {
+  float f = 0;
+  f += 0.5;
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: narrowing conversion from 'double' to 'float' [cppcoreguidelines-narrowing-conversions]
+  f += d;
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: narrowing conversion from 'double' to 'float' [cppcoreguidelines-narrowing-conversions]
+  // We warn on the following even though it's not dangerous because there is no
+  // reason to use a double literal here.
+  // TODO(courbet): Provide an automatic fix.
+  f += 2.0;
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: narrowing conversion from 'double' to 'float' [cppcoreguidelines-narrowing-conversions]
+
+  f *= 0.5;
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: narrowing conversion from 'double' to 'float' [cppcoreguidelines-narrowing-conversions]
+  f /= 0.5;
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: narrowing conversion from 'double' to 'float' [cppcoreguidelines-narrowing-conversions]
+  f += (double)0.5f;
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: narrowing conversion from 'double' to 'float' [cppcoreguidelines-narrowing-conversions]
+}
+
 void ok(double d) {
   int i = 0;
   i = 1;
   i = static_cast<int>(0.5);
   i = static_cast<int>(d);
   i = std::ceil(0.5);
   i = ::std::floor(0.5);
   {
     using std::ceil;
     i = ceil(0.5f);
   }
   i = ceil(0.5f);
 }
 
 void ok_binary_ops(double d) {
   int i = 0;
   i += 1;
   i += static_cast<int>(0.5);

 // We're bailing out in templates and macros.
 template <typename T1, typename T2>
 void f(T1 one, T2 two) {
   one += two;
 }
 
 void template_context() {
   f(1, 2);
+  f(1, .5f);
   f(1, .5);
+  f(1, .5l);
 }
 
 #define DERP(i, j) (i += j)
 
 void macro_context() {
   int i = 0;
   DERP(i, 2);
+  DERP(i, .5f);
   DERP(i, .5);
+  DERP(i, .5l);
 }
 
-}  // namespace floats
+} // namespace floats