[PATCH] D124613: In MSVC compatibility mode, friend function declarations behave as function declarations
Fred Tingaud via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Fri May 20 06:38:39 PDT 2022
frederic-tingaud-sonarsource added a comment.
@rnk Here is the test case that was broken: https://godbolt.org/z/Gef7PcqMf
One point where I was wrong in my initial analysis is that the behavior doesn't actually change based on `/std:c++17` VS `/std:c++latest`, but based on `/permissive` VS `/permissive-` (which is related because `/std:c++latest` automatically defaults on `/permissive-`). Other MSVC extensions should also depend on `/permissive`, such as clang-cl handles friend classes visibility or `ext_unqualified_base_class.`
I saw that clang-cl already parses the `/permissive` flag and translates it to `OPT__SLASH_Zc_twoPhase_` and `OPT_fno_operator_names`. Would it make sense to cover these extensions too? That would ensure conformant code is not broken by accident while giving people the possibility to parse their MSVC-specific code with more of its non-conformant specificities. But it does indeed increase the testing complexity.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D124613/new/
https://reviews.llvm.org/D124613
More information about the cfe-commits
mailing list