Clang creates implicit move constructor/assign operator in all cases if there is std=c++11. But MSVC supports such generation starting from version 1900 only. As result we have some binary incompatibility.
As mentioned twice in https://llvm.org/bugs/show_bug.cgi?id=27212, I don't think this is the right direction. To my knowledge, this only causes an ABI break when importing a class. I think we should change Sema::checkClassLevelDLLAttribute to not apply dllimport to implicit move special members instead.
Oh, so we were already doing this check. I don't see what's wrong with our current behavior, though. We export a few more symbols than MSVC 2013, but there's no ABI problem with that.
I've been trying to say that ABI compatibility is not the same thing as generating the same set of exported symbols, but it really doesn't matter. If MSVC 2013 and 2015 are not ABI compatible in this corner case, there is no need for clang to bend over backward to provide a marginally better experience. It sounds like it makes your life easier if we can always produce the exact same set of exports as the MSVC version we are targeting.