[clang-tidy] Introduce misc No Integer To Pointer Cast check

[lebedev.ri]

Summary

While casting an (integral) pointer to an integer is obvious - you just get
the integral value of the pointer, casting an integer to an (integral) pointer
is deceivingly different. While you will get a pointer with that integral value,
if you got that integral value via a pointer-to-integer cast originally,
the new pointer will lack the provenance information from the original pointer.

So while (integral) pointer to integer casts are effectively no-ops,
and are transparent to the optimizer, integer to (integral) pointer casts
are *NOT* transparent, and may conceal information from optimizer.

While that may be the intention, it is not always so. For example,
let's take a look at a routine to align the pointer up to the multiple of 16:
The obvious, naive implementation for that is:

char* src(char* maybe_underbiased_ptr) {
  uintptr_t maybe_underbiased_intptr = (uintptr_t)maybe_underbiased_ptr;
  uintptr_t aligned_biased_intptr = maybe_underbiased_intptr + 15;
  uintptr_t aligned_intptr = aligned_biased_intptr & (~15);
  return (char*)aligned_intptr; // warning: avoid integer to pointer casts [misc-no-inttoptr]
}

The check will rightfully diagnose that cast.

But when provenance concealment is not the goal of the code, but an accident,
this example can be rewritten as follows, without using integer to pointer cast:

char*
tgt(char* maybe_underbiased_ptr) {
    uintptr_t maybe_underbiased_intptr = (uintptr_t)maybe_underbiased_ptr;
    uintptr_t aligned_biased_intptr = maybe_underbiased_intptr + 15;
    uintptr_t aligned_intptr = aligned_biased_intptr & (~15);
    uintptr_t bias = aligned_intptr - maybe_underbiased_intptr;
    return maybe_underbiased_ptr + bias;
}

See also:

• D71499
• Juneyoung Lee, Chung-Kil Hur, Ralf Jung, Zhengyang Liu, John Regehr, and Nuno P. Lopes. 2018. Reconciling High-Level Optimizations and Low-Level Code in LLVM. Proc. ACM Program. Lang. 2, OOPSLA, Article 125 (November 2018), 28 pages.

[nlopes]

Nice!
BTW, another popular idiom is to store data in the last few bits of the pointer (e.g., LLVM's own PointerIntPair). I guess that one can also be implement by casting the ptr to char* and doing operations over that.

[tschuett]

Out of curiosity: why is this in clang-tidy and not in clang?

[lebedev.ri]

In D91055#2382112, @nlopes wrote:

Nice!

Why thank you.

BTW, another popular idiom is to store data in the last few bits of the pointer (e.g., LLVM's own PointerIntPair). I guess that one can also be implement by casting the ptr to char* and doing operations over that.

Yep, there is a number of such patterns.
My basic idea behind this patch is that it is very much non-obvious whether

1. such a cast was actually intended to be there
2. the provenance obscurement is intentional

so let's just diagnose everything, and the user can either silence it, or rewrite it without the cast.

In D91055#2382137, @tschuett wrote:

Out of curiosity: why is this in clang-tidy and not in clang?

Why should this be in clang?
I can't imagine it will pass the bar of no false-positives,
and silencing clang diag is not very convient..

[arichardson]

Nice! I wonder if this could be an off-by-default (maybe enabled by -Wpedantic) warning in clang instead?

Diagnostics like this could be very useful for CHERI since our capabilities are in some way tracking provenance in hardware: we have bounds, permissions and a validity bit for all pointers.
All pointers must be derived from another valid pointer (CHERI capability) otherwise the validity bit is cleared.
Casting from an integer to a pointer always results in a value without provenance (lacking a tag bit in hardware) and will result in traps when dereferenced.
We do however treat uintptr_t as carrying provenance (casts retain the same permissions+bounds+validity bit in hardware as the original pointer).

Out compiler has some diagnostics to flag int -> pointer casts, so we warn about the example code when using long as the intermediate value (since that will cause run-time crashes if the value is dereferenced), but we do not warn for uintptr_t:
CHERI compiler explorer

I just checked whether we emit diagnotics for the testscases here and discovered that we only diagnose explicit casts from (non-uintptr_t) int -> pointer as lacking provenance, but are missing warnings for the -Wint-conversion case.

[lebedev.ri]

CC'ing @rsmith regarding the suggestion/question of also having a clang diagnostic for this.

[tschuett]

I did not consider false positives, but it provides better visibility. It is always on.

[aaron.ballman]

In D91055#2382356, @lebedev.ri wrote:

CC'ing @rsmith regarding the suggestion/question of also having a clang diagnostic for this.

I'm not Richard, but I have some thoughts just the same. :-) The C committee is currently exploring questions of pointer provenance that may have impact in this area. You can see the proposed text for a TS on pointer provenance here: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2577.pdf The paper goes into a lot of detail about various provenance choices and how those choices impact existing code, implementations, optimization opportunities, etc. and my concern with adding a provenance check to the Clang frontend at this time is that LLVM may want to implement changes from that TS which may cause unfortunate code churn for users who enable the warning in Clang. I think keeping this check in clang-tidy gives us good utility for catching bugs today, but also gives us a safer place to react to changes in the C standard. At some point, I expect the question of how to track provenance to settle down within the committee and our implementation, and that would be a good time to consider lifting the analysis into Clang. CCing @nlopes @hfinkel @jeroen.dobbelaere and @jdoerfert to raise awareness on the provenance TS in case it wasn't yet on their radar.

[lebedev.ri]

ping

[lebedev.ri]

Ping.
If there's no pushback within next 24h i will commit this and wait for post-commit review (if any).
Thanks.

[aaron.ballman]

In D91055#2410447, @lebedev.ri wrote:

Ping.
If there's no pushback within next 24h i will commit this and wait for post-commit review (if any).
Thanks.

FWIW, that's not the way we usually do things, so please don't push and hope for post-commit review on something people have expressed questions/concerns over.

clang-tools-extra/clang-tidy/misc/MiscTidyModule.cpp

40 ↗

(On Diff #303775)

Is misc really the right place for this? If this is related to optimizer behavior, perhaps it should live in performance?

clang-tools-extra/clang-tidy/misc/NoIntToPtrCheck.cpp

26 ↗

(On Diff #303775)

This doesn't really tell the user what's wrong with their code or how to fix it. There are valid use cases for casting an integer into a pointer, after all. For instance, if I'm doing this cast because I'm trying to read a register bank:

volatile int *registers = (volatile int *)0xFEEDFACE;

what is wrong with my code and what should I do to silence this diagnostic?

Intuitively, one would think that use of intptr_t or uintptr_t would have some impact on this given the standard's requirements for that type in C17 7.20.1.4p1. Could there be a certain cast path that can be used to silence the diagnostic because it's safe enough for the optimizer's needs?

clang-tools-extra/docs/clang-tidy/checks/misc-no-inttoptr.rst

6 ↗

(On Diff #303775)

char buffer[16];
sprintf(buffer, "%p", ptr);

intptr_t val;
sscanf(buffer, "%" SCNxPTR, &val);

Do you think this check should catch such constructs under the same reasoning as other conversions that hide provenance?

12 ↗

(On Diff #303775)

Does this run afoul of the C++ standard's requirements for pointer traceability: http://eel.is/c++draft/basic.stc.dynamic.safety ?

clang-tools-extra/test/clang-tidy/checkers/misc-no-inttoptr.cpp

3 ↗

(On Diff #303775)

can not -> cannot
(same below)

[aqjune]

clang-tools-extra/docs/clang-tidy/checks/misc-no-inttoptr.rst

12 ↗

(On Diff #303775)

This is fine because the compiled IR is allowed to be more defined than the C++ source.

In C++, accessing a pointer that is derived from an integer is UB if it is out-of-bounds location of the object pointed by the integer.
In LLVM IR (I mean in the suggested memory model), it is relaxed to have well-defined behavior if the pointer is pointing to a different, but in-bounds location of an object.
This loses the precision of points-to analysis if inttoptr is involved, but makes more arithmetic optimizations on integers valid.

[lebedev.ri]

@aaron.ballman @aqjune thank you for taking a look!

Rebased, mostly addressed review notes:

• Moved into performance module
• Don't diagnose casts of integer literals

[aaron.ballman]

There are a couple of questions from the previous iteration of the review that aren't answered yet:

• the diagnostic wording doesn't actually say what's wrong with the code or how to fix it; how should users silence the diagnostic if they've found a case where it's a false positive for some reason?
• do you expect this check to catch other hidden provenance gotchas like grabbing values through printf/scanf, fread, etc)? (Not for this patch iteration, just wondering if you expect to extend the check in the future.)

clang-tools-extra/clang-tidy/performance/NoIntToPtrCheck.cpp

22

Do we also want to exclude the case where the destination is a volatile pointer on the assumption that something out of the ordinary is going on. e.g.,

intptr_t addr;
if (something) {
  addr = SOME_CONSTANT;
} else {
  addr = SOME_OTHER_CONSTANT;
}
volatile int *register_bank = (volatile int *)addr;

clang-tools-extra/clang-tidy/performance/PerformanceTidyModule.cpp

53

Does anyone else have opinions on inttoptr vs int-to-ptr? I feel like the latter is easier to read than the former, but I'm wondering if I'm just strange.

clang-tools-extra/docs/clang-tidy/checks/list.rst

23

It looks like there's a whole bunch of unrelated changes happening here?

[lebedev.ri]

Ugh, i really hate that inline comments aren't submitted upon uploading the new diff, it catches me off-guard each time...

clang-tools-extra/clang-tidy/misc/MiscTidyModule.cpp

40 ↗

(On Diff #303775)

Yeah, i'm not sure. performance does seem like a marginally better place for this, so let's go with that.

clang-tools-extra/clang-tidy/misc/NoIntToPtrCheck.cpp

26 ↗

(On Diff #303775)

A cast from literal is a good point, we should not warn on those,
especially because those are most likely some predefined hardcoded hw registers.

Intuitively, one would think that use of intptr_t or uintptr_t would have some impact on this given the standard's requirements for that type in C17 7.20.1.4p1. Could there be a certain cast path that can be used to silence the diagnostic because it's safe enough for the optimizer's needs?

Do you mean

uintptr_t x = <>;
void *y = (void*)(x)

or

void *x = <>;
void *y = (void*)((uintptr_t)x)

The former is literally the case this check should warn on.
As for the latter, also not really, because like i have already stated,
such cast pair is used to be treated as opaque (and dropped by the optimizer),
but that is changing.

TLDR: no

clang-tools-extra/docs/clang-tidy/checks/misc-no-inttoptr.rst

6 ↗

(On Diff #303775)

I'm open to suggestions as to how to title it more precisely given the idea underneath.

To recap, the check should warn on all the casts that may involve an unintentional,
subtle, unobvious cast from an integer to a pointer.
That example doesn't strike me as potentially unintentional,
while (void*)((uintptr_t)x & -16) does.

The obvious cast i guess i'd be fine with would be synthesize_pointer_from_integer_cast<>(),
but there isn't one now.

[aaron.ballman]

clang-tools-extra/clang-tidy/misc/NoIntToPtrCheck.cpp

26 ↗

(On Diff #303775)

Okay, thank you for the explanation. I think it's fine to not have a way to silence the diagnostic (users can use // NOLINT, pragmas, etc), but I think the diagnostic should be made a bit more verbose so it's clear why. How about: integer to pointer cast pessimizes optimization opportunities?

clang-tools-extra/docs/clang-tidy/checks/misc-no-inttoptr.rst

6 ↗

(On Diff #303775)

Okay, I think the check is fine as-is then. This isn't a "catch all the ways users can lose provenance information in a way that matters" check, it's a "catch the most common ways users do that" check. If we need a stronger variant of the check, we can add it to the static analyzer at that point.

[lebedev.ri]

@aaron.ballman thank you for taking a look!
Addressing review notes:

• s/inttoptr/int-to-ptr/
• Adjust diagnostic to be more descriptive of the problem

[aaron.ballman]

LGTM!

clang-tools-extra/clang-tidy/performance/NoIntToPtrCheck.cpp

22

On reflection, I think we can make an adjustment here if there's user feedback that it's a frequent false positive.

[lebedev.ri]

In D91055#2440344, @aaron.ballman wrote:

LGTM!

Thank you for the review!

clang-tools-extra/clang-tidy/performance/CMakeLists.txt

 set(LLVM_LINK_COMPONENTS
   FrontendOpenMP
   Support
   )
 
 add_clang_library(clangTidyPerformanceModule
   FasterStringFindCheck.cpp
   ForRangeCopyCheck.cpp
   ImplicitConversionInLoopCheck.cpp
   InefficientAlgorithmCheck.cpp
   InefficientStringConcatenationCheck.cpp
   InefficientVectorOperationCheck.cpp
   MoveConstArgCheck.cpp
   MoveConstructorInitCheck.cpp
   NoAutomaticMoveCheck.cpp
+  NoIntToPtrCheck.cpp
   NoexceptMoveConstructorCheck.cpp
   PerformanceTidyModule.cpp
   TriviallyDestructibleCheck.cpp
   TypePromotionInMathFnCheck.cpp
   UnnecessaryCopyInitialization.cpp
   UnnecessaryValueParamCheck.cpp
 
   LINK_LIBS

clang-tools-extra/clang-tidy/performance/NoIntToPtrCheck.h

+//===--- NoIntToPtrCheck.h - clang-tidy -------------------------*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_PERFORMANCE_NOINTTOPTRCHECK_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_PERFORMANCE_NOINTTOPTRCHECK_H
+
+#include "../ClangTidyCheck.h"
+
+namespace clang {
+namespace tidy {
+namespace performance {
+
+/// Diagnoses every integer to pointer cast.
+///
+/// For the user-facing documentation see:
+/// http://clang.llvm.org/extra/clang-tidy/checks/performance-no-int-to-ptr.html
+class NoIntToPtrCheck : public ClangTidyCheck {
+public:
+  NoIntToPtrCheck(StringRef Name, ClangTidyContext *Context)
+      : ClangTidyCheck(Name, Context) {}
+  void registerMatchers(ast_matchers::MatchFinder *Finder) override;
+  void check(const ast_matchers::MatchFinder::MatchResult &Result) override;
+};
+
+} // namespace performance
+} // namespace tidy
+} // namespace clang
+
+#endif // LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_PERFORMANCE_NOINTTOPTRCHECK_H

clang-tools-extra/clang-tidy/performance/NoIntToPtrCheck.cpp

+//===--- NoIntToPtrCheck.cpp - clang-tidy ---------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#include "NoIntToPtrCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+namespace performance {
+
+void NoIntToPtrCheck::registerMatchers(MatchFinder *Finder) {
+  Finder->addMatcher(castExpr(hasCastKind(CK_IntegralToPointer),
+                              unless(hasSourceExpression(integerLiteral())))
+                         .bind("x"),
+                     this);
+}
+
+void NoIntToPtrCheck::check(const MatchFinder::MatchResult &Result) {
+  const auto *MatchedCast = Result.Nodes.getNodeAs<CastExpr>("x");
+  diag(MatchedCast->getBeginLoc(),
+       "integer to pointer cast pessimizes optimization opportunities");
+}
+
+} // namespace performance
+} // namespace tidy
+} // namespace clang

clang-tools-extra/clang-tidy/performance/PerformanceTidyModule.cpp

 #include "ForRangeCopyCheck.h"
 #include "ImplicitConversionInLoopCheck.h"
 #include "InefficientAlgorithmCheck.h"
 #include "InefficientStringConcatenationCheck.h"
 #include "InefficientVectorOperationCheck.h"
 #include "MoveConstArgCheck.h"
 #include "MoveConstructorInitCheck.h"
 #include "NoAutomaticMoveCheck.h"
+#include "NoIntToPtrCheck.h"
 #include "NoexceptMoveConstructorCheck.h"
 #include "TriviallyDestructibleCheck.h"
 #include "TypePromotionInMathFnCheck.h"
 #include "UnnecessaryCopyInitialization.h"
 #include "UnnecessaryValueParamCheck.h"
 
 namespace clang {
 namespace tidy {
void addCheckFactories(ClangTidyCheckFactories &CheckFactories) override {
     CheckFactories.registerCheck<InefficientVectorOperationCheck>(
         "performance-inefficient-vector-operation");
     CheckFactories.registerCheck<MoveConstArgCheck>(
         "performance-move-const-arg");
     CheckFactories.registerCheck<MoveConstructorInitCheck>(
         "performance-move-constructor-init");
     CheckFactories.registerCheck<NoAutomaticMoveCheck>(
         "performance-no-automatic-move");
+    CheckFactories.registerCheck<NoIntToPtrCheck>("performance-no-int-to-ptr");
     CheckFactories.registerCheck<NoexceptMoveConstructorCheck>(
         "performance-noexcept-move-constructor");
     CheckFactories.registerCheck<TriviallyDestructibleCheck>(
         "performance-trivially-destructible");
     CheckFactories.registerCheck<TypePromotionInMathFnCheck>(
         "performance-type-promotion-in-math-fn");
     CheckFactories.registerCheck<UnnecessaryCopyInitialization>(
         "performance-unnecessary-copy-initialization");

clang-tools-extra/docs/ReleaseNotes.rst

- New :doc:`bugprone-signal-handler
   functions.
 
 - New :doc:`cert-sig30-c
   <clang-tidy/checks/cert-sig30-c>` check.
 
   Alias to the :doc:`bugprone-signal-handler
   <clang-tidy/checks/bugprone-signal-handler>` check.
 
+- New :doc:`performance-no-int-to-ptr
+  <clang-tidy/checks/performance-no-int-to-ptr>` check.
+
+  Diagnoses every integer to pointer cast.
+
 - New :doc:`readability-function-cognitive-complexity
   <clang-tidy/checks/readability-function-cognitive-complexity>` check.
 
   Flags functions with Cognitive Complexity metric exceeding the configured limit.
 
 Changes in existing checks
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 

clang-tools-extra/docs/clang-tidy/checks/list.rst

.. csv-table::
    `abseil-duration-addition <abseil-duration-addition.html>`_, "Yes"
    `abseil-duration-comparison <abseil-duration-comparison.html>`_, "Yes"
    `abseil-duration-conversion-cast <abseil-duration-conversion-cast.html>`_, "Yes"
    `abseil-duration-division <abseil-duration-division.html>`_, "Yes"
    `abseil-duration-factory-float <abseil-duration-factory-float.html>`_, "Yes"
    `abseil-duration-factory-scale <abseil-duration-factory-scale.html>`_, "Yes"
    `abseil-duration-subtraction <abseil-duration-subtraction.html>`_, "Yes"
    `abseil-duration-unnecessary-conversion <abseil-duration-unnecessary-conversion.html>`_, "Yes"
    `abseil-faster-strsplit-delimiter <abseil-faster-strsplit-delimiter.html>`_, "Yes"
    `abseil-no-internal-dependencies <abseil-no-internal-dependencies.html>`_,
    `abseil-no-namespace <abseil-no-namespace.html>`_,
    `abseil-redundant-strcat-calls <abseil-redundant-strcat-calls.html>`_, "Yes"
    `abseil-str-cat-append <abseil-str-cat-append.html>`_, "Yes"
    `abseil-string-find-startswith <abseil-string-find-startswith.html>`_, "Yes"
    `abseil-string-find-str-contains <abseil-string-find-str-contains.html>`_, "Yes"
    `abseil-time-comparison <abseil-time-comparison.html>`_, "Yes"
    `abseil-time-subtraction <abseil-time-subtraction.html>`_, "Yes"
.. csv-table::
    `performance-for-range-copy <performance-for-range-copy.html>`_, "Yes"
    `performance-implicit-conversion-in-loop <performance-implicit-conversion-in-loop.html>`_,
    `performance-inefficient-algorithm <performance-inefficient-algorithm.html>`_, "Yes"
    `performance-inefficient-string-concatenation <performance-inefficient-string-concatenation.html>`_,
    `performance-inefficient-vector-operation <performance-inefficient-vector-operation.html>`_, "Yes"
    `performance-move-const-arg <performance-move-const-arg.html>`_, "Yes"
    `performance-move-constructor-init <performance-move-constructor-init.html>`_, "Yes"
    `performance-no-automatic-move <performance-no-automatic-move.html>`_,
+   `performance-no-int-to-ptr <performance-no-int-to-ptr.html>`_,
    `performance-noexcept-move-constructor <performance-noexcept-move-constructor.html>`_, "Yes"
    `performance-trivially-destructible <performance-trivially-destructible.html>`_, "Yes"
    `performance-type-promotion-in-math-fn <performance-type-promotion-in-math-fn.html>`_, "Yes"
    `performance-unnecessary-copy-initialization <performance-unnecessary-copy-initialization.html>`_,
    `performance-unnecessary-value-param <performance-unnecessary-value-param.html>`_, "Yes"
    `portability-restrict-system-includes <portability-restrict-system-includes.html>`_, "Yes"
    `portability-simd-intrinsics <portability-simd-intrinsics.html>`_,
    `readability-avoid-const-params-in-decls <readability-avoid-const-params-in-decls.html>`_,

clang-tools-extra/docs/clang-tidy/checks/performance-no-int-to-ptr.rst

+.. title:: clang-tidy - performance-no-int-to-ptr
+
+performance-no-int-to-ptr
+=========================
+
+Diagnoses every integer to pointer cast.
+
+While casting an (integral) pointer to an integer is obvious - you just get
+the integral value of the pointer, casting an integer to an (integral) pointer
+is deceivingly different. While you will get a pointer with that integral value,
+if you got that integral value via a pointer-to-integer cast originally,
+the new pointer will lack the provenance information from the original pointer.
+
+So while (integral) pointer to integer casts are effectively no-ops,
+and are transparent to the optimizer, integer to (integral) pointer casts
+are *NOT* transparent, and may conceal information from optimizer.
+
+While that may be the intention, it is not always so. For example,
+let's take a look at a routine to align the pointer up to the multiple of 16:
+The obvious, naive implementation for that is:
+
+.. code-block:: c++
+
+  char* src(char* maybe_underbiased_ptr) {
+    uintptr_t maybe_underbiased_intptr = (uintptr_t)maybe_underbiased_ptr;
+    uintptr_t aligned_biased_intptr = maybe_underbiased_intptr + 15;
+    uintptr_t aligned_intptr = aligned_biased_intptr & (~15);
+    return (char*)aligned_intptr; // warning: avoid integer to pointer casts [performance-no-int-to-ptr]
+  }
+
+The check will rightfully diagnose that cast.
+
+But when provenance concealment is not the goal of the code, but an accident,
+this example can be rewritten as follows, without using integer to pointer cast:
+
+.. code-block:: c++
+
+  char*
+  tgt(char* maybe_underbiased_ptr) {
+      uintptr_t maybe_underbiased_intptr = (uintptr_t)maybe_underbiased_ptr;
+      uintptr_t aligned_biased_intptr = maybe_underbiased_intptr + 15;
+      uintptr_t aligned_intptr = aligned_biased_intptr & (~15);
+      uintptr_t bias = aligned_intptr - maybe_underbiased_intptr;
+      return maybe_underbiased_ptr + bias;
+  }

clang-tools-extra/test/clang-tidy/checkers/performance-no-int-to-ptr.c

+// RUN: %check_clang_tidy %s performance-no-int-to-ptr %t
+
+void *t0(char x) {
+  return x;
+  // CHECK-MESSAGES: [[@LINE-1]]:10: warning: integer to pointer cast pessimizes optimization opportunities [performance-no-int-to-ptr]
+}
+void *t1(signed char x) {
+  return x;
+  // CHECK-MESSAGES: [[@LINE-1]]:10: warning: integer to pointer cast pessimizes optimization opportunities [performance-no-int-to-ptr]
+}
+void *t2(unsigned char x) {
+  return x;
+  // CHECK-MESSAGES: [[@LINE-1]]:10: warning: integer to pointer cast pessimizes optimization opportunities [performance-no-int-to-ptr]
+}
+
+void *t3(short x) {
+  return x;
+  // CHECK-MESSAGES: [[@LINE-1]]:10: warning: integer to pointer cast pessimizes optimization opportunities [performance-no-int-to-ptr]
+}
+void *t4(unsigned short x) {
+  return x;
+  // CHECK-MESSAGES: [[@LINE-1]]:10: warning: integer to pointer cast pessimizes optimization opportunities [performance-no-int-to-ptr]
+}
+void *t5(signed short x) {
+  return x;
+  // CHECK-MESSAGES: [[@LINE-1]]:10: warning: integer to pointer cast pessimizes optimization opportunities [performance-no-int-to-ptr]
+}
+
+void *t6(int x) {
+  return x;
+  // CHECK-MESSAGES: [[@LINE-1]]:10: warning: integer to pointer cast pessimizes optimization opportunities [performance-no-int-to-ptr]
+}
+void *t7(unsigned int x) {
+  return x;
+  // CHECK-MESSAGES: [[@LINE-1]]:10: warning: integer to pointer cast pessimizes optimization opportunities [performance-no-int-to-ptr]
+}
+void *t8(signed int x) {
+  return x;
+  // CHECK-MESSAGES: [[@LINE-1]]:10: warning: integer to pointer cast pessimizes optimization opportunities [performance-no-int-to-ptr]
+}
+
+void *t9(long x) {
+  return x;
+  // CHECK-MESSAGES: [[@LINE-1]]:10: warning: integer to pointer cast pessimizes optimization opportunities [performance-no-int-to-ptr]
+}
+void *t10(unsigned long x) {
+  return x;
+  // CHECK-MESSAGES: [[@LINE-1]]:10: warning: integer to pointer cast pessimizes optimization opportunities [performance-no-int-to-ptr]
+}
+void *t11(signed long x) {
+  return x;
+  // CHECK-MESSAGES: [[@LINE-1]]:10: warning: integer to pointer cast pessimizes optimization opportunities [performance-no-int-to-ptr]
+}
+
+void *t12(long long x) {
+  return x;
+  // CHECK-MESSAGES: [[@LINE-1]]:10: warning: integer to pointer cast pessimizes optimization opportunities [performance-no-int-to-ptr]
+}
+void *t13(unsigned long long x) {
+  return x;
+  // CHECK-MESSAGES: [[@LINE-1]]:10: warning: integer to pointer cast pessimizes optimization opportunities [performance-no-int-to-ptr]
+}
+void *t14(signed long long x) {
+  return x;
+  // CHECK-MESSAGES: [[@LINE-1]]:10: warning: integer to pointer cast pessimizes optimization opportunities [performance-no-int-to-ptr]
+}

clang-tools-extra/test/clang-tidy/checkers/performance-no-int-to-ptr.cpp

+// RUN: %check_clang_tidy %s performance-no-int-to-ptr %t
+
+// can't implicitly cast int to a pointer.
+// can't use static_cast<>() to cast integer to a pointer.
+// can't use dynamic_cast<>() to cast integer to a pointer.
+// can't use const_cast<>() to cast integer to a pointer.
+
+void *t0(long long int x) {
+  return (void *)x;
+  // CHECK-MESSAGES: [[@LINE-1]]:10: warning: integer to pointer cast pessimizes optimization opportunities [performance-no-int-to-ptr]
+}
+
+void *t1(int x) {
+  return reinterpret_cast<void *>(x);
+  // CHECK-MESSAGES: [[@LINE-1]]:10: warning: integer to pointer cast pessimizes optimization opportunities [performance-no-int-to-ptr]
+}
+
+// Don't diagnose casts from integer literals.
+// It's a widely-used technique in embedded/microcontroller/hardware interfacing.
+void *t3(long long int x) {
+  return (void *)0xFEEDFACE;
+}