Lexer/__has_declspec_attribute regression in Clang 14

[lilianmoraru]

Regression tracked to this commit: 2edb89c#diff-d8dd6191130efea27aca1a54b23fc45eeeb1cc377147f9d6f5ec8b00ff56fafc
Confirmed that reverting 2edb89c746848c52964537268bf03e7906bf2542 on d8e0e125a2ff03335838039f5d33ecd61dfec654(main branch/clang 14) fixes the bug.

Description:

libcurl 7.78.0(the line was there for years, it's not specific to this version) fails to compile when consumed in a C++ project(unknown if specific to C++ - this was the initial setup when the issue was hit):

linux/include/curl/curl.h:120:41: error: too few arguments provided to function-like macro invocation
      __has_declspec_attribute(dllimport))
                                        ^

Clang 13.0.1(release/13.x branch) works fine.
Clang 14(d8e0e125a2ff03335838039f5d33ecd61dfec654, branch main) fails.

This is the line upstream:
https://github.com/curl/curl/blob/bfbde883af33397943df68a3ae01847a634d33bf/include/curl/curl.h#L120

Attaching the libcurl source code used in the project(note: not building libcurl itself, just consuming the curl.h header):
libcurl.zip

[llvmbot]

@llvm/issue-subscribers-clang-frontend

[lilianmoraru]

Is there a way for me to help move this along for LLVM 14?

[lilianmoraru]

The regression is still present in LLVM 14.0.0-rc4.

[tstellar]

@AaronBallman Can you take a look at this?

[AaronBallman]

I'm not able to reproduce on Windows, but I suspect that's expected (I don't have a Linux box handy to test on at the moment). I'm also not able to reproduce on godbolt (even after adding the includes I spotted): https://godbolt.org/z/zPTjbo6nY, but they don't have curl as a library option so I can't test exactly. I looked through the curl source attached and didn't spot the obvious culprit (#define dllimport(something)), but that's ultimately what the issue is presenting as -- we're lexing a token we expect to be expandable and we can't because something defined the token as a function-like macro.

Could you take Clang 13 and run a -E -dD invocation over your test and attach the resulting preprocessed content? That could help us spot where dllimport is being defined as a macro (if it is indeed being defined as one).