On Sat, Jul 27, 2013 at 11:48 AM, Aaron Ballman <[email protected]> wrote: > This patch fixes a few cases where a default destructor would not be > generated due to a member variable having an inaccessible default > destructor. While the original code was correct, the updated code is > a bit more clear. Assuming that this new code is acceptable, this > also re-enables the C4624 MSVC warning (''derived class' : destructor > could not be generated because a base class destructor is > inaccessible').
That code change does seem a bit strange/questionable/unnecessary. While I'm OK enabling warnings in MSVC that have some substantial overlap with Clang warnings to help developers working with MSVC keep their work Clang-clean, generally we've taken the line that if a warning isn't viable for Clang, it's not worth turning on in some other compiler for LLVM. Does this warning catch useful bugs? (Why would you need a warning for cases when a dtor couldn't be generated when you'd get an error if/when you actually call that dtor? (because that latter warning is hard to understand? That would be unfortunate)) I wonder why making an explicit dtor works? If the base class dtor is inaccessible, wouldn't it still be inaccessible even in an explicit dtor? (& can we workaround this some other way? What happens if the default ctor uses LLVM_DELETED_FUNCTION instead of an empty definition, does that suppress the dtor warning? I doubt it, but figured I'd throw that out there...) _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
