thakis added a comment. Thanks, reverted in e0fcdf5496ca686c8cebb63b63af86e666b42ab3 <https://reviews.llvm.org/rGe0fcdf5496ca686c8cebb63b63af86e666b42ab3> for now.
In D124613#3511098 <https://reviews.llvm.org/D124613#3511098>, @frederic-tingaud-sonarsource wrote: > I realized that this current patch does in fact mimic MSVC behavior up to its > mishandling of compliant code. I understand that it is not in the spirit of > clang's MSVC compatibility to have that, but the fixed version I was about to > propose would stray away from MSVC behavior, which doesn't really make sense > either. > So instead I think the right approach should be to revert and see later > whether we could put it back under the hood of another flag. > Is there currently a flag that could be used for "potentially C++ compliant > breaking MSVC compatibility"? If there isn't, would it make sense to propose > one? I'm not sure we want to add this. The current setup seems to be working reasonably well, and adding a 3rd ms compat flag (in addition to -fms-extensions and -fms-compatibility) seems like a fairly expensive thing (from a testing pov) compared to the benefit: Your clients will have to update their code for this for msvc with c++20 anyways. How difficult is it for your clients to make their code standards compliant for this particular thing? How many instances would they have to update? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D124613/new/ https://reviews.llvm.org/D124613 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
