__inline causes header to fail to parse, when it succeeds in MSVC

[wmmc88]

I was trying to parse a Windows header (ufxclient.h) using clang with the msvc compatibility flags (-fms-compatibility -fms-extensions) and ended up with the following error:

  error: 'inline' can only appear on functions

I managed to narrow the issue down to several typdef definitions in the header that erroneously add FORCEINLINE to a function ptr typedef. This is one of them:

typedef
_IRQL_requires_max_(DISPATCH_LEVEL)
WDFQUEUE
FORCEINLINE
UFX_ENDPOINT_GET_COMMAND_QUEUE (
    _In_ PUFX_GLOBALS,
    _In_ UFXENDPOINT
    );
typedef UFX_ENDPOINT_GET_COMMAND_QUEUE *PFN_UFX_ENDPOINT_GET_COMMAND_QUEUE;

MSVC successfully compiles this definition, but clang fails with the above error, even with all the ms compatibility flags/extensions enabled. I think clang should loosen this error to a warning so that the code still compiles. Or should allow this completely when the ms-compat options are enabled.

Minimal repros :

Passing in MSVC: https://godbolt.org/z/59MYbebax
Hard Error in Clang: https://godbolt.org/z/W8cs54oo6
Warning in Gcc, but still succeeds to compile: https://godbolt.org/z/Tbv7PsbKr

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Melvin Wang (wmmc88)

I was trying to parse a Windows header (`ufxclient.h`) using clang with the msvc compatibility flags (`-fms-compatibility -fms-extensions`) and ended up with the following error: ``` error: 'inline' can only appear on functions ```

I managed to narrow the issue down to several typdef definitions in the header that erroneously add FORCEINLINE to a function ptr typedef. This is one of them:

typedef
_IRQL_requires_max_(DISPATCH_LEVEL)
WDFQUEUE
FORCEINLINE
UFX_ENDPOINT_GET_COMMAND_QUEUE (
    _In_ PUFX_GLOBALS,
    _In_ UFXENDPOINT
    );
typedef UFX_ENDPOINT_GET_COMMAND_QUEUE *PFN_UFX_ENDPOINT_GET_COMMAND_QUEUE;

MSVC successfully compiles this definition, but clang fails with the above error, even with all the ms compatibility flags/extensions enabled. I think clang should loosen this error to a warning so that the code still compiles. Or should allow this completely when the ms-compat options are enabled.

Minimal repros :

Passing in MSVC: https://godbolt.org/z/59MYbebax
Hard Error in Clang: https://godbolt.org/z/W8cs54oo6
Warning in Gcc, but still succeeds to compile: https://godbolt.org/z/Tbv7PsbKr

[shafik]

CC @AaronBallman

[AaronBallman]

Yeah, it seems defensible for us to simply drop the inline specifier in this particular case. Note, MSVC accepts __inline and inline (we should also check things like __forceinline, etc)

[AaronBallman]

One thing that's interesting to note is that Microsoft only supports that in C, not in C++: https://godbolt.org/z/fYsrhsGPs

[wmmc88]

Thanks for the quick fix @AaronBallman!

Am I correct in assuming that this change won't be released until LLVM 20?

[AaronBallman]

I think it's probably safe enough that we could backport it given that it impacts a system header. However, I'm a bit curious how a C++ compilation handles that header file given that MSVC gives an error on the construct. Did Microsoft already fix this on their end?

[wmmc88]

However, I'm a bit curious how a C++ compilation handles that header file given that MSVC gives an error on the construct. Did Microsoft already fix this on their end?

I think the answer is that it doesn't. I was able to repro the issue you described when compiling for C++ with that header. I am not affiliated with any of the teams which own this, but I've let them know about it!

I think it's probably safe enough that we could backport it given that it impacts a system header

This would mean it'd be available in something like a v19.1.8? Is there going to be another v19 release?

[AaronBallman]

I think the answer is that it doesn't. I was able to repro the issue you described when compiling for C++ with that header. I am not affiliated with any of the teams which own this, but I've let them know about it!

Thank you!

This would mean it'd be available in something like a v19.1.8? Is there going to be another v19 release?

I don't think there will be any more 19.x releases; we just cut the branch for Clang 20 this week. So I'm porting to 20.x instead of it waiting for 21.x, but 19.x is going to be stuck I believe. CC @tstellar @tru in case they want to put out a 19.x given that this impacts a system header.