[all-commits] [llvm/llvm-project] a34f24: [libc++][ABI BREAK] Do not use the C++03 emulation...

[Louis Dionne via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: a34f24689945e967e4ba4d79ed301d3a71870c7b
      https://github.com/llvm/llvm-project/commit/a34f24689945e967e4ba4d79ed301d3a71870c7b
  Author: Louis Dionne <ldionne.2 at gmail.com>
  Date:   2021-11-30 (Tue, 30 Nov 2021)

  Changed paths:
    M libcxx/docs/ReleaseNotes.rst
    M libcxx/include/__config

  Log Message:
  -----------
  [libc++][ABI BREAK] Do not use the C++03 emulation for std::nullptr_t by default

We only support Clangs that implement nullptr as an extension in C++03 mode,
and we don't support GCC in C++03 mode. Hence, this patch disables the
use of the std::nullptr_t emulation in C++03 mode by default. Doing that
is technically an ABI break since it changes the mangling for std::nullptr_t.
However:

(1) The only affected users are those compiling in C++03 mode that have
    std::nullptr_t as part of their ABI, which should be reasonably rare.

(2) Those users already have a lingering problem in that their code will
    be incompatible in C++03 and C++11 modes because of that very ABI break.
    Hence, the only users that could really be inconvenienced about this
    change is those that planned on compiling in C++03 mode forever - for
    other users, we're just breaking them now instead of letting them break
    themselves later on when they try to upgrade to C++11.

(3) The ABI break will cause a linker error since the mangling changed,
    and will not result in an obscure runtime error.

Furthermore, if anyone is broken by this, they can define the
_LIBCPP_ABI_USE_CXX03_NULLPTR_EMULATION macro to return to the
previous behavior. We will then remove that macro after shipping
this for one release if we haven't seen widespread issues.

Concretely, the motivation for making this change is to make our own ABI
consistent in C++03 and C++11 modes and to remove complexity around the
definition of nullptr.

Furthermore, we could investigate making nullptr a keyword in C++03 mode
as a Clang extension -- I don't think that would break anyone, since
libc++ already defines nullptr as a macro to something else. Only users
that do not use libc++ and compile in C++03 mode could potentially be
broken by that.

Differential Revision: https://reviews.llvm.org/D109459