BumpPtrAllocator and dtors on Windows

windows

(Saleem Abdulrasool) #1

When building swift with cl, I find that the triviality tests fail for the BumpPtrAllocations. I was wondering if there is a good way to address this issue. It seems unfortunate that we cannot build the compiler with cl, as it does help significantly with debugging issues on Windows itself (as opposed to building with clang-cl) as the quality of the debug information generated is far better (yes, there are improvements to be made to clang, but that seems like it would be a really wide tangent).

Is the best option for now to just silence the fact that the dtors are not being invoked?

CC: @jrose


(Jordan Rose) #2

I…guess? But it'd be much better to find out why those types aren't considered trivial on Windows, if that's possible.


(Saleem Abdulrasool) #3

Okay, seems that there are only a handful of them. At least one of them is due to Optional<UUID>. I'm not sure why that is not trivial, UUID is definitely trivial.


(Joe Groff) #4

There was an upstream change to llvm::Optional to disable its triviality-forwarding because of a gcc bug IIRC.


(Saleem Abdulrasool) #5

I just tracked it down to something related. It seems that the isPodLike is incorrect for MSVC's C++ (it doesn't account for it). That should fix it, but need time to build/test.


(Jordan Rose) #6

I think @Bob_Wilson reverted this in swift-clang because it broke other things.


(Bob Wilson) #7

Yes. See https://reviews.llvm.org/D54540

That optimization (which I restored in swift-clang until we get a fix in upstream LLVM) is specific to Clang and GCC, so it wouldn't affect MSVC.


(Bob Wilson) #8

Oh wait, I mis-read the code. It is only disabled for GCC.


(Saleem Abdulrasool) #9

I tracked it down. The problem was that the LLVM trait didnt use std::is_trivially_copyable. I fixed this upstream and created a PR for swift-5.0-branch.