Skip to content

Deprecated attribute not honoured on partial template specialization #44496

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ldionne opened this issue Mar 9, 2020 · 1 comment · Fixed by #138426
Closed

Deprecated attribute not honoured on partial template specialization #44496

ldionne opened this issue Mar 9, 2020 · 1 comment · Fixed by #138426
Labels
bugzilla Issues migrated from bugzilla clang:frontend Language frontend issues, e.g. anything involving "Sema"

Comments

@ldionne
Copy link
Member

ldionne commented Mar 9, 2020

Bugzilla Link 45151
Version trunk
OS All
CC @dwblaikie,@zygoloid

Extended Description

In the following code, the deprecated attribute does not fire. I believe that is because it is applied to a partial specialization:

cat <<EOF | clang++ -xc++ -
template <typename T> class function { };
template <typename A>
class __attribute__((deprecated)) function<void(A)> { };
int main() { function<void(int)> f; }
EOF

Live repro: https://wandbox.org/permlink/5IAXzJOYCpPuCbok

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 10, 2021
@frederick-vs-ja
Copy link
Contributor

frederick-vs-ja commented Aug 2, 2024

What's worse, Clang currently implements [[deprecated]] and __attribute__((deprecated)) in a self-suppressing manner (Godbolt link).

#ifdef USE_GNU_SYNTAX // It doesn't matter whether the standard syntax is used.
#define DEPRECATED __attribute__((deprecated))
#else
#define DEPRECATED [[deprecated]]
#endif

// Additional [[deprecated]] on a partial specialization possibly suppresses deprecation warnings with Clang!
#ifdef USE_ANOTHER_DEPRECATED
#define ANOTHER_DEPRECATED DEPRECATED
#else
#define ANOTHER_DEPRECATED
#endif 

template<class>
struct my_template {
    using type = void;
};

template<class T>
struct DEPRECATED deprecated_type_identity { using type = T; }; // workaround for Clang, but...

template<class T>
struct ANOTHER_DEPRECATED my_template<volatile T> : deprecated_type_identity<volatile T> {};

template<class T>
using my_template_t = typename my_template<T>::type;

int main()
{
    using X [[maybe_unused]] = my_template<volatile int>; // Clang doesn't seem able to warn, sadly.
    using Z [[maybe_unused]] = my_template_t<volatile int>; // Here!
}

cor3ntin added a commit to cor3ntin/llvm-project that referenced this issue May 3, 2025
…zations

There are some limitations.

Because we only know which partial
specialization to refer to when instantiating, and because we
can't instantiate the class before we require a complete type,
we can only use the partial specialization once we have a complete
class.

Similarly, because we don't know if a class is ever going to be
complete, we always always warn on avaibility of the primary.
Therefore we only warn fr the partial specialization if we did
not warn on the primary.

I considered alternatives to address that second limitation:
 - Delay warnings to the end of the TU
 - Tracking where each avaibility attribute originally comes from.

However, both of these have drawbacks, and the use case is probably
less motivated than wanting to deprecate the use of a
specific specialization.

Fixes llvm#44496
GeorgeARM pushed a commit to GeorgeARM/llvm-project that referenced this issue May 7, 2025
…lizations (llvm#138426)

There are some limitations.

Because we only know which partial specialization to refer to when
instantiating, and because we can't instantiate the class before we
require a complete type, we can only use the partial specialization once
we have a complete class.

Similarly, because we don't know if a class is ever going to be
complete, we always warn on availability of the primary. Therefore, we
only warn for the partial specialization if we did not warn on the
primary.

I considered alternatives to address that second limitation:
 - Delay warnings to the end of the TU
 - Tracking where each availability attribute originally comes from.

However, both of these have drawbacks, and the use case is probably less
motivated than wanting to deprecate the use of a specific
specialization.

Fixes llvm#44496
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla clang:frontend Language frontend issues, e.g. anything involving "Sema"
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants