[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