The code below is valid in MSVC, but it is not allowed in clang
printf(__FUNCTION__ "Hello World");
This patch fixes the compatibility with MSVC.
Differential D136343
[Lex] Add compatibility with MSVC Qfrost911 on Oct 20 2022, 5:38 AM. Authored by
Details
The code below is valid in MSVC, but it is not allowed in clang printf(__FUNCTION__ "Hello World"); This patch fixes the compatibility with MSVC.
Diff Detail Event TimelineComment Actions Thank you for the patch! It looks like it's missing test coverage for the changes, can you add some to clang/test/Preprocessor? One question I have is: if we're going to support __FUNCTION__, shouldn't we also support __FUNCDNAME__ and __FUNCSIG__ as well, as those are also Microsoft predefined macros in the same general space?
Comment Actions Correct! We have a PredefinedExpr AST node type (https://github.com/llvm/llvm-project/blob/main/clang/include/clang/AST/Expr.h#L1968) to handle this, and it seems we already support __FUNCTION__ (and friends): https://godbolt.org/z/cEWh1Prnx. However, we're matching the GCC behavior for printing a member function name instead of following the MSVC behavior when in -fms-compatibility mode, which we might want to consider changing. The reason your code example in the summary doesn't compile is because a PredefinedExpr is not a string literal, so there is no way to do string concatenation with an adjacent literal. MSVC implements these as actual macros that expand to a string literal, which is not a behavior Clang can easily match. Comment Actions I understand you mean. I think I can try to solve this problem, if I have enough time. Thank you very much for your response. |
You should put your declaration on a new line so the line length doesn't exceed 80 columns (it's part of our coding style: https://llvm.org/docs/CodingStandards.html).