From 927394cafccdaf9a8cef53c0793f310bb8868f48 Mon Sep 17 00:00:00 2001
From: Dimitry Andric <dim@FreeBSD.org>
Date: Tue, 6 Sep 2016 20:01:15 +0000
Subject: [PATCH] =?UTF-8?q?=EF=BB=BFMove=20inclusion=20of=20<cstdio>=20and?=
 =?UTF-8?q?=20<cstdlib>=20in=20the=20-fno-exceptions=20case=20to=20the=20e?=
 =?UTF-8?q?nd=20of=20libc++'s=20<exception>.=20=20This=20is=20a=20workarou?=
 =?UTF-8?q?nd=20for=20building=20Firefox,=20which=20generates=20a=20rather?=
 =?UTF-8?q?=20convoluted=20maze=20of=20standard=20library=20wrapper=20head?=
 =?UTF-8?q?ers,=20and=20this=20leads=20to=20an=20unfortunate=20sequence=20?=
 =?UTF-8?q?of:?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

1. wrapper <new> includes libc++ <new>,
2. which includes wrapper <exception>,
3. which includes libc++ <exception>,
4. which includes wrapper <cstdio> (because of -fno-exception),
5. which includes libc++ <new> again,
6. which includes mozalloc.h,
7. which tries to declare operator new with std::bad_alloc,
8. which gives an error because std::bad_alloc is not yet defined.

The <new> inclusion at step 5 does nothing, because the header guard for
<new> was already encountered in step 1.  Then when moz_alloc.h tries to
use std::bad_alloc, it is not yet defined, because we are still busy
processing <exception> (where this class is defined) from step 3.

Mozilla has https://bugzilla.mozilla.org/show_bug.cgi?id=1269171 for
this, reported by Jan Beich (jbeich@), but when the fix for it is
applied to Firefox, we get into another, similar problem situation:

1. some header includes wrapper <exception>,
2. which includes libc++ <exception>,
3. which includes wrapper <cstdio> (because of -fno-exceptions),
4. which includes mozalloc.h,
5. which includes wrapper <new>,
6. which includes libc++ <new>,
7. which gives an error defining std::bad_alloc, because std::exception
   is not yet defined.

At step 3, we were at the top of libc++'s <exception>, and at that point
std::exception is not yet defined.  At step 6, <new> does include
<exception> again, but similar to step 5 in the previous problem case,
the header guard was already encountered, so the whole header is
skipped.

In upstream libc++'s later revisions r279744 and r279763, the reason for
including <cstdio> and <cstdlib> was nullified again, but these commits
are rather large and intrusive.  Therefore, move the includes to the
bottom of the file, just before where they are needed.  At that point,
std::exception is already fully defined.

Suggested by:	Jörg Sonnenberger
---
 contrib/libc++/include/exception | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/contrib/libc++/include/exception b/contrib/libc++/include/exception
index 186d379f08f5..14eede2127bd 100644
--- a/contrib/libc++/include/exception
+++ b/contrib/libc++/include/exception
@@ -80,10 +80,6 @@ template <class E> void rethrow_if_nested(const E& e);
 #include <__config>
 #include <cstddef>
 #include <type_traits>
-#if defined(_LIBCPP_NO_EXCEPTIONS)
-#include <cstdio>
-#include <cstdlib>
-#endif
 
 #if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
 #pragma GCC system_header
@@ -255,6 +251,11 @@ rethrow_if_nested(const _Ep&, typename enable_if<
 
 }  // std
 
+#if defined(_LIBCPP_NO_EXCEPTIONS)
+#include <cstdio>
+#include <cstdlib>
+#endif
+
 _LIBCPP_BEGIN_NAMESPACE_STD
 
 template <class _Exception>