I have removed this option from in the libc++ in r272613. I believe it has no clients.
If anybody uses this option please contact me.
This option was used to turn off std::pair’s trivial copy constructor, instead selecting an older non-trivial implementation.
It was added in r194742, on November 14th 2013. At that time Apple platforms used this option to turn off pairs trivial constructor. Two weeks later, on November 26th 2013, the default value for Apple platforms was removed in r195796.
Defining _LIBCPP_TRIVIAL_PAIR_COPY_CTOR will now cause an explicit error informing the client that the option has been removed. I will remove this diagnostic after the 3.9 release.
If the option is completely removed, we will either have to supply two versions of libc++, or bolt on some sort of backwards compatibility versioned symbols. Alternatively, we can add a local hack to put back the non-trivial copy constructor, but that might lead to other headaches.
David, do you have any good ideas for this? I think your idea was to burn all backwards compatibility bridges, but we can’t really do that for FreeBSD 11.0 at this point, so we would have to start backporting fixes from trunk libc++, instead of importing it wholesale. For FreeBSD 12.0 we could ship only the new libc++, and provide the older libc++ as a compatibility package.
Well that’s unfortunate I’ll revert it later today, and we can work on a solution from there.
I would strongly encourage you to submit FreeBSD specific patches upstream. It’s very helpful to see who (if anybody) is using specific ABI options or seemingly dead conditional compilation branches.
Thinking out loud: The Itanium spec specifies that the calling conventions for non-trivial types only occurs when both the copy constructor and destructor are trivial.
I have some upcoming changes to pair that depend on the copy constructor being implicitly generated, which means killing those constructors.
Perhaps we could find another way to make either the destructor or implicitly generated copy constructor non-trivial?
I wonder if giving pair a dummy base class with a non-trivial destructor could serve as an alternative solution?
I’ll revert it later today, and we can work on a solution from there.