[PATCH] D66770: Move EH spec mismatches under -fms-compatibility

Stephan T. Lavavej via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Aug 26 16:19:00 PDT 2019


STL_MSFT added a comment.

This will definitely help us clean up our code, since we run the MSVC STL test suite with `-fno-ms-compatibility -fno-delayed-template-parsing`.

Other possible occurrences of ms-extensions that should be considered ms-compatibility:

- ParseDeclCXX.cpp says "MSVC permits pure specifier on inline functions defined at class scope." which sounds like a rule relaxation.
- Parser.cpp says "MS compatibility: MSVC permits using known types with typename. e.g. "typedef typename T* pointer_type"" while downgrading an error to a warning. Seems like this should be ms-compatibility.
- SemaCast.cpp says "C++ 5.2.10p4: A pointer can be explicitly converted to any integral type large enough to hold it; except in Microsoft mode, where the integral type size doesn't matter (except we don't allow bool)." This definitely seems like ms-compatibility.
- ParseExprCXX.cpp says "We have something like t::getAs<T>, where getAs is a member of an unknown specialization. However, this will only parse correctly as a template, so suggest the keyword 'template' before 'getAs' and treat this as a dependent template name." while downgrading an error to a warning.

I might regret asking about some of these, if Clang begins erroring on WinSDK etc. code that can't be rapidly updated.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D66770/new/

https://reviews.llvm.org/D66770





More information about the cfe-commits mailing list