[clang-tidy] Unclear purpose/usefulness/actionability of `portability-template-virtual-member-function`

[carlosgalvezp]

I came across the portability-template-virtual-member-function check and don't really understand how the check is useful or actionable. It's not clear as a user what I'm supposed to do to "fix" the code and silence the warning.

The example in the docs shows that there's a compiler error, but that compiler error is not visible in GCC or Clang because the function is not instantiated. It is however visible in MSVC because it is instantiated.

I see two possible scenarios:

• I only ever use GCC/Clang, then I can just disable the check.
• I use both GCC/Clang and MSVC, in which case I'll get a compiler error from MSVC, prompting me to fix the compiler error (that goes unnoticed by GCC). Once I fix the compiler error, clang-tidy still complains, even though I've resolved the actual issue.

So I personally do not see the value in this check, it only bans the usage of virtual member functions in class templates. I would vote for removing it altogether, or at the very least improving the docs to show how people are supposed to fix their code to comply with the check.

[llvmbot]

@llvm/issue-subscribers-clang-tidy

Author: Carlos Galvez (carlosgalvezp)

I came across the `portability-template-virtual-member-function` check and don't really understand how the check is useful or actionable. It's not clear as a user what I'm supposed to do to "fix" the code and silence the warning.

The example in the docs shows that there's a compiler error, but that compiler error is not visible in GCC or Clang because the function is not instantiated. It is however visible in MSVC because it is instantiated.

I see two possible scenarios:

• I only ever use GCC/Clang, then I can just disable the check.
• I use both GCC/Clang and MSVC, in which case I'll get a compiler error from MSVC, prompting me to fix the compiler error (that goes unnoticed by GCC). Once I fix the compiler error, clang-tidy still complains, even though I've resolved the actual issue.

So I personally do not see the value in this check, it only bans the usage of virtual member functions in class templates. I would vote for removing it altogether, or at the very least improving the docs to show how people are supposed to fix their code to comply with the check.

[vbvictor]

CC @isuckatcs as author.

[vbvictor]

We have checks with similar semantics: portability-avoid-pragma-once, portability-std-allocator-const. They just ban certain language constructs because they will give errors on some compilers. So I think we should not remove template-virtual-function but maybe give a better name like avoid-template-...

[carlosgalvezp]

But the usage of virtual functions in template classes is not the problem per se, they are perfectly valid in all compilers. It's just that if you have a random compiler error inside them, you may or may not notice it.

The only way to comply with this check is to ban virtual functions in template classes, even though they are supported by all compilers, which does not seem useful. The other checks you mention are indeed things that are compiler-specific or not allowed by the standard.

[vbvictor]

Thank you for the details. Then it seems odd that with this check we only try to avoid a random error in msvc compiler that could be fixed any day (or already fixed)

[carlosgalvezp]

Sorry, what I meant by "random compiler error" is that the user writes arbitrary code that should not compile - I did not mean an MSVC bug/error.

In the provided example:

    virtual void unused() {
        T MSVCError = this;  // illegal code if T cannot be constructed from a MSVCError type
    };

The code inside the unused function is incorrect/illegal, because it assumes any type T can be constructed from a MSVCError, which is not true. If the function was empty, then the code would compile fine on any compiler.

So in my opinion this check would only be hiding real user implementation issues.