[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