Various cleanup, corrections, clarification, etc

Author: jeremy-rifkin

README.md

@@ -479,9 +479,10 @@ namespace cpptrace {
 
 ### Logging
 
-Cpptrace attempts to gracefully recover from any internal errors. By default, cpptrace doesn't log anything to the
-console in order to avoid interfering with user programs. However, there are a couple configurations that can be used
-to set a custom logging behavior or enable logging to stderr.
+Cpptrace attempts to gracefully recover from any internal errors in order to provide the best information it can and not
+interfere with user applications. However, sometimes it's important to see what's going wrong inside cpptrace if
+anything does go wrong. To facilitate this, cpptrace has an internal logger. By default it doesn't log anything out. The
+following configurations that can be used to set a custom logging callback or enable logging to stderr:
 
 ```cpp
 namespace cpptrace {
@@ -577,23 +578,23 @@ CPPTRACE_TRY {
 }
 ```
 
-> [!CAUTION]
-> There is a footgun with `return` statements in these try/catch macros: The implementation on Windows requires wrapping
-> the try body in an immediately-invoked lambda and and as such `return` statements return from the lambda not the
-> enclosing function. If you're writing code that will be compiled on windows, it's important to not write `return`
-> statements within CPPTRACE_TRY. E.g., this does not work as expected on windows:
+> [!WARNING]
+> There is an unfortunate limitation with `return` statements in these try/catch macros: The implementation on Windows
+> requires wrapping the try body in an immediately-invoked lambda and and as such `return` statements would return from
+> the lambda not the enclosing function. Cpptrace guards against misleading `return`s compiling by requiring the lambdas
+> to return a special internal type, but, if you're writing code that will be compiled on windows it's important to not
+> write `return` statements within CPPTRACE_TRY. For example, this is invalid:
 > ```cpp
 > CPPTRACE_TRY {
->     if(condition) return 40; // does not return from the enclosing function on windows
+>     if(condition) return 40; // error, type int doesn't match cpptrace::detail::dont_return_from_try_catch_macros
 > } CPPTRACE_CATCH(const std::exception& e) {
 >     ...
 > }
-> return 20;
 > ```
 
 > [!WARNING]
-> There is one other footgun which is mainly relevant for code that was written on an older version of cpptrace: It's
-> possible to write the following without getting errors
+> There is a footgun which is mainly relevant for code that was written on an older version of cpptrace: It's possible
+> to write the following without getting errors
 > ```cpp
 > CPPTRACE_TRY {
 >     ...
@@ -603,9 +604,9 @@ CPPTRACE_TRY {
 >     ...
 > }
 > ```
-> This code will compile and in some sense work as expected as the second catch handler will work, however, cpptrace
-> won't know about the handler and as such it would be able to correctly collect a trace on a non-`std::runtime_error`
-> that is thrown. No run-time errors will occur, however, `from_current_exception` may report a misleading trace.
+> This code will compile and the second catch handler will work, however, cpptrace won't know about the handler and as
+> such it won't be able to correctly collect a trace when a type that does not match `std::runtime_error` is thrown. No
+> run-time errors will occur, however, `from_current_exception` will report a misleading trace.
 
 ### Removing the `CPPTRACE_` prefix
 

src/platform/exception_type.hpp

@@ -17,7 +17,7 @@ namespace detail {
     inline std::string exception_type_name() {
         #if defined(CPPTRACE_HAS_CXX_EXCEPTION_TYPE) && (IS_LIBSTDCXX || IS_LIBCXX)
          const std::type_info* t = abi::__cxa_current_exception_type();
-         return t ? demangle(t->name(), false) : "<unknown>";
+         return t ? detail::demangle(t->name(), false) : "<unknown>";
         #else
          return "<unknown>";
         #endif

src/utils.cpp

@@ -14,16 +14,6 @@
  #include <unistd.h>
 #endif
 
-CPPTRACE_BEGIN_NAMESPACE
-namespace detail {
-    const formatter& get_terminate_formatter() {
-        static formatter the_formatter = formatter{}
-            .header("Stack trace to reach terminate handler (most recent call first):");
-        return the_formatter;
-    }
-}
-CPPTRACE_END_NAMESPACE
-
 CPPTRACE_BEGIN_NAMESPACE
     std::string demangle(const std::string& name) {
         return detail::demangle(name, false);
@@ -47,6 +37,14 @@ CPPTRACE_BEGIN_NAMESPACE
      extern const int stderr_fileno = STDERR_FILENO;
     #endif
 
+    namespace detail {
+        const formatter& get_terminate_formatter() {
+            static formatter the_formatter = formatter{}
+                .header("Stack trace to reach terminate handler (most recent call first):");
+            return the_formatter;
+        }
+    }
+
     CPPTRACE_FORCE_NO_INLINE void print_terminate_trace() {
         try { // try/catch can never be hit but it's needed to prevent TCO
             detail::get_terminate_formatter().print(std::cerr, generate_trace(1));

src/utils/result.hpp

@@ -71,7 +71,9 @@ namespace detail {
             return *this;
         }
         Result& operator=(Result&& other)
-            noexcept(std::is_nothrow_move_assignable<value_type>::value && std::is_nothrow_move_constructible<value_type>::value)
+            noexcept(
+                std::is_nothrow_move_constructible<value_type>::value && std::is_nothrow_move_constructible<E>::value
+            )
         {
             if (this != &other) {
                 destroy();

test/link_test.cpp

@@ -85,6 +85,10 @@ int main() {
     cpptrace::experimental::set_dwarf_resolver_line_table_cache_size(100);
     cpptrace::experimental::set_dwarf_resolver_disable_aranges(true);
 
+    cpptrace::detail::lazy_trace_holder lh;
+    lh.is_resolved();
+
     cpptrace::basename("");
     cpptrace::prettify_symbol("");
+    cpptrace::prune_symbol("");
 }