MaxEW707 wrote: > The scenario I am thinking about is when the user passed -fms-extensions and > no other individual flags. I think that mode should enable all of the > Microsoft extensions. Then users can opt out of whatever extensions they > don't want to enable. But I think it's confusing if -fms-extensions still > requires the user to explicitly opt in to other Microsoft-specific extensions.
That is a fair point. I did some further digging. Starting with C++20 MSVC starting enforcing various C++ conformance options by default. For example `/permissive-` is the default now meaning `/Zc:referenceBinding` is set. MSVC does not allow its custom reference binding rules by default anymore. Godbolt for reference: https://godbolt.org/z/6hTeGeb6x. We already do similar behaviour in the driver for the `delayed-template-parsing` extension. `delayed-template-parsing`, called `/Zc:twoPhase-` in MSVC driver parlance, is enabled by default if we are windows msvc and not C++20 since MSVC does two-phase lookup by default in C++20 onwards. In this PR I now enable `ms-reference-binding` by default if we are windows msvc and not C++20 as well to imitate MSVC behaviour. `ms-reference-binding` is still an individual controllable option and is also properly set if you use the `/permissive` or `/permissive-` larger group option in the cl driver mode. I wrote up a small gist here about what `-fms-extensions` covers, https://gist.github.com/MaxEW707/3fbb3a223710b6aa9269f7ffbdccbfc9. Most of it are things that you always want if you are targeting msvc which include the implicit `_GUID` struct, calling convention identifiers like `__stdcall`, SEH identifiers like `__finally`, Microsoft pragma support, builtin macros like `_WCHAR_T_DEFINED`, imitating MSVC PP token pasting behaviour, handling ^Z EOF in the lexer, etc. It also includes Microsoft extensions that do not have a conformance mode toggle currently in MSVC such as allowing a static declaration to follow an extern declaration, allowing inline function definitions on pure virtual methods, allowing type definitions inside an anonymous union/struct, etc. Most of these extensions in this category so far are fairly benign and don't alter the language semantics much compared to two-phase lookup or reference binding for example. Let me know if this is a satisfactory compromise :). I think it models what seems to be the precedent especially around two-phase lookup. https://github.com/llvm/llvm-project/pull/99833 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
