Change LLVM_ATTRIBUTE_DEPRECATED macro to [[deprecated]]

The LLVM_ATTRIBUTE_DEPRECATED macro marks e.g. function declarations as deprecated.

C++14 introduced the [[deprecated]] attribute, and I would like to switch LLVM’s code to that because it’s portable, easier to read, and can be applied to inline functions as well.

https://reviews.llvm.org/D94219 is the first step towards that by changing the LLVM_ATTRIBUTE_DEPRECATED implementation from attribute/__declspec to [[deprecated]]. In a follow-up change, I will switch the call sites to use [[deprecated]] directly and finally remove the macro.

Are there any downsides that I’m missing or any objections?

Thanks! Christian

Sounds good. D94219 as the first step is also safer: if some supported compilers
have problems, we can catch the problem without causing churn to use sites.

One potential issue is the possible existence of compilers that claim to support C++14, but are not fully compliant. I don’t know offhand of any examples of “C++14 compliant” compilers that don’t support [[deprecated]] but it may be worth looking into if any mainstream compilers have this problem. Assuming such a compiler exists, and we care about it, the macro has the advantage that it can be made to be portable.

That issue aside, since we require C++14 in CMake, then I think it’s fine to move forward with this.

Thanks,

Christopher Tetreault

The only downside I'm aware of is

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96117

I don't think the llvm build uses export macros, but are there any places where different attribute types are used?

Thanks,

Stephen.

One potential issue is the possible existence of compilers that claim to support C++14, but are not fully compliant.

At least from the compilers listed here, all of them support the [[deprecated]] attribute.

The only downside I’m aware of is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96117

Thanks for pointing that out Stephen. I couldn’t find any instance where LLVM_ATTRIBUTE_DEPRECATED is used in combination with another attribute and gcc’s deficiency doesn’t manifest itself on functions (https://godbolt.org/z/er9Pax), so hopefully this is only a theoretical problem.

If there are no objections, I will go ahead with D94219 and wait two weeks to see if any problems pop up before changing the call sites.