Workarounds that test for specific compilers

[alexbock]

I work on an external tool that consumes C++ source code, and many of our users apply it to programs that include headers from the Visual Studio STL. We sometimes need to release updated configurations for compatibility after Visual Studio updates that introduce the use of new compiler intrinsics. I have noticed that in typical instances of this, the maintainers have already identified the same area as a compatibility issue and included workarounds using #ifdef. These workarounds typically check for specific built-in compiler definitions such as __CUDACC__. This makes it difficult for other tools beyond CUDA to temporarily enable the same workaround, as the same macro is used to apply a number of independent workarounds in various files. I don't want built-in definitions to turn into user agent strings where everyone is pretending to be CUDA, EDG, and Mozilla to try to get the right definitions. Avoiding this often requires more nuanced macro definition overrides to introduce a workaround into the non-workaround case.

How would you feel about including a distinct "feature test name" for these cases? E.g. #if defined(__CUDACC__) || defined(__STL_WORKAROUND_BUILTIN_BIT_CAST__) instead of #ifdef __CUDACC__? If there is an opportunity to introduce such names for a new workaround prior to the release of Visual Studio update, would you be open to pull requests that add names for upcoming workarounds where relevant to other tools?

[MikeGitb]

Disclaimer: I'm not connected to this project.

What would be the policy to eventually remove those workaround names? I'd guess for supported compilers/tools the STL team can (in their abundant free time) check if a workaround is still necessary and remove it. But such config/feature macros would effectively become part of the STL's API.

[alexbock]

I would not expect any guarantees to be made regarding the lifetime of workarounds. The intention is that for however long the workaround is required for CUDA, it can be used for other programs without pretending to be CUDA. It would provide some buffer time after Visual Studio updates where users of programs that are mid-release-cycle can utilize existing workarounds by simply defining a macro until such programs are updated. With most programs that parse C++ source code now utilizing Clang or EDG as a front end, the implementation of new compiler intrinsics in future updates should be consistent.

That does suggest an alternative solution to avoid any implications associated with providing a name: basing #ifs on the underlying version of the front end rather than the specific front end user. The CUDA compiler appears to use Clang, and a Clang version check would be more generally applicable to other programs using Clang.

I also noticed that there is an instance of:

#if defined(_IS_ASSIGNABLE_NOCHECK_SUPPORTED) && !defined(__CUDACC__)

in type_traits, so perhaps this topic has arisen before.

[MikeGitb]

One possible (but work intensive) approach would be:

• Every workaround gets its config macro
• At a central header, the STL maintainers set the necessary macros for each supported toolchain
• Other toolchains could set the necessary macros themselves if necessary
• Use a script to check, if any supportet toolchain still sets the workaround and if not, remove the macro and the workaround completely.

[cbezault]

We discussed this and feel that this is a non-goal and would require an excessive amount of labor to maintain.
We already support two front-ends which are designed to work well with tooling, Clang and EDG.

The points that @MikeGitb make are also all good ones.