Enable CTRE_FORCE_INLINE when clang or gcc is integrated in MSVC

[Andersama]

When other compilers are integrated into the MSVC their compiler macros are defined in addition to _MSC_VER. Which confusingly means _MSC_VER only means the MSVC compiler if and only if no other compiler is detected.

[hanickadot]

What about ICC and EDG?

[Andersama]

I'd guess if they're properly integrated it's the same behavior? Is there a way to detect those?

[hanickadot]

Are you sure there is no other way how to detect MSVC without negating other compilers? That seems brittle to me.

[Andersama]

Not sure, I honestly just ran into this issue only because I just managed to get clang working for msvc and I only caught it because of debugging the assembly. There may be an easier way, but apparently as is, clang basically ignores __forceinline because it doesn't know what that is, kind of surprised it didn't error out or give a warning.

I'm not finding anything other than _MSC_VER being noted as the way to detect the MSVC compiler, but clearly that wasn't quite right.

Well, apparently _MSC_VER isn't specific to MSVC, intel's compiler apparently also defines it. Might be that _MSC_VER could be the IDE in general? Could be the MSVC compiler, could be the intel compiler (I don't know if intel's compiler has weird quirks like MSVC or they're defining both). This bit might need to be slightly more complicated than it ought to be.

[Andersama]

I wouldn't necessarily trust this, _MSC_BUILD seems to be different between whether I'm using MSVC specifically, or another compiler, that might be a short-hand way of checking.

[Andersama]

Looks like MSVC might always define __EDG__ because it's using EDG as a frontend for intellisense?
https://devblogs.microsoft.com/cppblog/use-any-c-compiler-with-visual-studio/

[Andersama]

Intel's compiler appears to use __forceinline? I'm not sure what the EDG compiler wants, I'm guessing since MSVC uses it __forceinline is what it would expect?

[Andersama]

p1007r1 appears to do this:

#if defined(__clang__) || defined(__GNUC__)
__attribute__((always_inline))
#elif defined(_MSC_VER)
__forceinline
#endif

Which would seem to avoid the weird MVSC issue, but wouldn't handle other compilers the same.

Could rewrite like:

#if defined(__clang__) || defined(__GNUC__)
__attribute__((always_inline))
#elif defined(_MSC_VER)
__forceinline
#else
__attribute__((always_inline))
#endif

To keep everything else the same.

[Andersama]

Here's a question, is there a particular reason why CTLL_FORCE_INLINE and CTRE_FORCE_INLINE are defined differently besides

compile-time-regular-expressions/include/ctll/parser.hpp

Line 44 in 0e646f3

constexpr inline CTLL_FORCE_INLINE operator bool() const noexcept {

Having inline already in the function signature? Seems CTLL_FORCE_INLINE and CTRE_FORCE_INLINE would be the same thing?

[hanickadot]

CTLL and CTRE can be used separately.

[Andersama]

Right, I guess my question is about the macro's usage, are CTLL_FORCE_INLINE and CTRE_FORCE_INLINE meant to be different really in any way? It looks as though from the way CTLL_FORCE_INLINE used you're adding an inline before the macro, where for CTRE_FORCE_INLINE you don't?

[hanickadot]

They should be same, but they probably are out of sync.

[Andersama]

Ah, ok was worried I was missing something weird about inlining because of how the signature would end up.

[Andersama]

@hanickadot not having luck on finding anything specific about the intel or edg compilers for force inline. Best I've run into is:
https://software.intel.com/content/www/us/en/develop/documentation/oneapi-dpcpp-cpp-compiler-dev-guide-and-reference/top/compiler-reference/attributes.html and https://www.edg.com/docs/edg_cpp.pdf

I found the attribute always_inline mentioned here for intel:
https://software.intel.com/content/www/us/en/develop/documentation/cpp-compiler-developer-guide-and-reference/top/compiler-reference/compiler-options/compiler-option-details/profile-guided-optimization-pgo-options/p.html

Best I can gauge without having access to either is intel and edg's compiler can parse msvc's attribute syntax. EDG reads as though it might ignore / not implement them. Not found __forceinline for eaither, so both might really use:

#define CTRE_FORCE_INLINE inline __attribute__((always_inline))

So it might look like:

#if defined(__INTEL_COMPILER) || defined(__EDG__) || defined(__clang__) || defined(__GNUC__)
#define CTRE_FORCE_INLINE inline __attribute__((always_inline))
#elif defined(_MSC_VER)
#define CTRE_FORCE_INLINE __forceinline
#else
#define CTRE_FORCE_INLINE inline __attribute__((always_inline))
#endif

[remyjette]

I know this is an old thread, but chiming in here - because _MSC_VER is defined when clang is building in msvc compatibility mode (via clang-cl), the addition of the changes in 9572913 to add [[msvc::flatten]] raises the diagnostic -Wunknown-attributes on clang-cl builds:

ctre\ctre.hpp(5598,37): fatal error: unknown attribute 'flatten' ignored [-Wunknown-attributes]
template <ctll::fixed_string input> CTRE_FLATTEN constexpr CTRE_FORCE_INLINE auto operator""_ctre() noexcept {
                                    ^~~~~~~~~~~~
ctre\ctre.hpp(1409,24): note: expanded from macro 'CTRE_FLATTEN'
#define CTRE_FLATTEN [[msvc::flatten]]

[hanickadot]

oh no :(