https://bugs.llvm.org/show_bug.cgi?id=42100
Bug ID: 42100
Summary: Implementing COM interfaces in MinGW broken by "Add
Attribute NoThrow as an Exception Specifier Type"
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected]
The recent change "Add Attribute NoThrow as an Exception Specifier Type"
(https://reviews.llvm.org/D62435, SVN r362119) broke code implementing COM
interfaces for the MinGW target.
Such code often ends up looking like this:
class Base {
public:
virtual __declspec(nothrow) void foo() = 0;
};
class Sub : public Base {
public:
void foo() { }
};
Before this change, this never even warned (and doesn't warn with GCC either,
nor with MSVC). After this change, this is suddenly a hard error without a way
to disable the error.
One could of course fix the code to add the same attribute at the
implementation of the interface as well, but this seems to be the common
pattern of how one implements a COM interface, so I would expect there to be a
lot of code out there looking exactly like this.
By adding -fms-extensions, it is turned into a warning instead of an error
though, thanks to the following bit in lib/Sema/SemaExceptionSpec.cpp in
Sema::CheckOverridingFunctionExceptionSpec:
unsigned DiagID = diag::err_override_exception_spec;
if (getLangOpts().MicrosoftExt)
DiagID = diag::ext_override_exception_spec;
Now for the MinGW case, the ideal would be to only degrade this to a warning
for cases with `__declspec(nothrow)`, not for the proper C++11 noexcept
specifier.
Do you (Reid and Erich) have any opinions on this? Is it better to change "Add
Attribute NoThrow as an Exception Specifier Type" to not do it for the MinGW
case at all (which would match GCC), or to degrade all exception spec
mismatches to warnings for this target?
--
You are receiving this mail because:
You are on the CC list for the bug._______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
