performance-unnecessary-value-param.AllowedTypes has inconsistent behavior when namespaces and type aliases are involved

[nvartolomei]

Example:

---
Checks: '-*,performance-*'
CheckOptions:
  - key:             performance-unnecessary-value-param.AllowedTypes
    value:           a::dt;

namespace a {

struct dt {
  ~dt(){};
};

using a_dt_alias = a::dt;

} // namespace a

void f1(a::dt in) {};

void f2(a::a_dt_alias in) {};

warning: the parameter 'in' is copied for each invocation but only used as a const reference; consider making it a const reference [performance-unnecessary-value-param]
   13 | void f2(a::a_dt_alias in) {};
      |                       ^
      |         const        &

If namespace is removed from code and from clang-tidy config then no warnings are generated.

[llvmbot]

@llvm/issue-subscribers-clang-tidy

Author: Nicolae Vartolomei (nvartolomei)

Example:

---
Checks: '-*,performance-*'
CheckOptions:
  - key:             performance-unnecessary-value-param.AllowedTypes
    value:           a::dt;

namespace a {

struct dt {
  ~dt(){};
};

using a_dt_alias = a::dt;

} // namespace a

void f1(a::dt in) {};

void f2(a::a_dt_alias in) {};

warning: the parameter 'in' is copied for each invocation but only used as a const reference; consider making it a const reference [performance-unnecessary-value-param]
   13 | void f2(a::a_dt_alias in) {};
      |                       ^
      |         const        &

If namespace is removed from code and from clang-tidy config then no warnings are generated.

[vbvictor]

I think the check behavior is correct, there is a purpose why alias was created, so we better treat it as a "separate type" in AllowedTypes.
The workaround is simply putting a::a_dt_alias in the list.

[vbvictor]

Moreover, I can imagine a codebase that will do something like:

namespace a {

struct heavy {
  ~heavy(){};
};

using light = a::dt;

} // namespace a

void f1(a::heavy in) {}; // warning

void f2(a::light in) {}; // no warning

So we can warn on all occurrences of heavy but not on occurrences of light.

[nvartolomei]

In my case I see people creating aliases to avoid typing long names especially when they are templates. I don’t follow the light/heavy argument (I assume the alias aliases heavy struct). Why it would be desirable to silence warning for one but not for the other? They are the same types so have the same cost, right?

…

On Fri, 20 Jun 2025 at 17:44, Baranov Victor ***@***.***> wrote: *vbvictor* left a comment (llvm/llvm-project#145032) <#145032 (comment)> Moreover, I can imagine a codebase that will do something like: namespace a { struct heavy { ~heavy(){}; }; using light = a::dt; } // namespace a void f1(a::heavy in) {}; // warning void f2(a::light in) {}; // no warning So we can warn on all occurrences of heavy but not on occurrences of light . — Reply to this email directly, view it on GitHub <#145032 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEETWJJKOBX5ISZR5PMMNL3EQ27RAVCNFSM6AAAAAB7YHVAAKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSOJSGIZTIMBQGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[vbvictor]

Yes, they can have same size (unless its int compiled on x32 and x64), but

struct A {
    int32_t a;
    int32_t b;
}

Can be light on x64 but considered heavy on x32

[nvartolomei]

Unfortunately I still don’t understand your point about what type aliases have to do with this. If the aliased type is considered “light” under what circumstances the alias type (the one declared with using keyword) would be desirable to not fall under that categorization and you’d want a warning to be issued? Would appreciate a real world example. My example is we have a custom shared pointer type, let’s call it seastar::shared_ptr<T> and I don’t want warnings to be issued when it is passed by value similar to std::shared_ptr<T>. But then, there are places where we define e.g. `using type_ptr = seastar::shared_ptr<Type>` (this is quite common, there are probably dozens of these) and I don’t want warnings for these type_ptrs issued either.

…

On Fri, 20 Jun 2025 at 20:07, Baranov Victor ***@***.***> wrote: *vbvictor* left a comment (llvm/llvm-project#145032) <#145032 (comment)> Yes, they can have same size (unless its int compiled on x32 and x64), but struct { int32_t a; int32_t b; } Can be light on x64 but considered heavy on x32 — Reply to this email directly, view it on GitHub <#145032 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEETWNOCQ4WINSR6LPPSW33ERLWJAVCNFSM6AAAAAB7YHVAAKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSOJSGU3DMOBTHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>