BumpPtrAllocator and dtors on Windows

Development Compiler
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

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.

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.

4

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

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.

2 Likes
6

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

1 Like
7

Yes. See ⚙ D54540 [ADT] Drop llvm::Optional clang-specific optmization for trivially copyable types

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.

8

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

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.

3 Likes