Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.42%. Comparing base (880f7bc) to head (6cc6157).
Report is 629 commits behind head on master.

@@           Coverage Diff           @@
##           master   #15353   +/-   ##
=======================================
  Coverage   98.42%   98.42%           
=======================================
  Files         161      161           
  Lines       21249    21249           
=======================================
  Hits        20915    20915           
  Misses        334      334           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
     mimxrt:    +0 +0.000% TEENSY40
        rp2:    +0 +0.000% RPI_PICO_W
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS

The idea is sound, but this implementation isn't ideal. For instance: imo external code shouldn't include py/stackctrl.h directly, but py/runtime.h instead. On the other hand here's the list of headers I've been using for embedding the windows and unix ports:

#ifdef __cplusplus
extern "C"
{
#endif
#include <py/objfun.h>
#include <py/objint.h>
#include <py/objmodule.h>
#include <py/objtype.h>
#include <py/runtime.h>
#ifdef __cplusplus
}
#endif

and some of these are lacking here. So I think either the situation should remain as-is, or we'd have to settle on which files form the toplevel api and then modify those. Or maybe even provide one common header which is C++ compatible, but that has the (slight) disadvantage that it's going to include more than needed for most users.

I'm unclear how to give this PR a Zephyr tag. Also I'd like to mention that this PR doesn't attempt to implement C++ compatibility for all ports, just Zephyr.

I'm unclear how to give this PR a Zephyr tag. Also I'd like to mention that this PR doesn't attempt to implement C++ compatibility for all ports, just Zephyr.

The changes here are not zephyr specific, they apply to everything (all ports), so they need to work with everything.

In general this should be usable by anyone embedding MicroPython in a C++ project.

I've been embedding C++ code into MicroPython builds since 0cf12dd, this being the core of our (probably not wise in retrospect) software strategy at Pimoroni.

I've found that introducing C++ code into MicroPython also brings a lot of C++ baggage and footguns- while these may be manageable for a seasoned C++ developer, wider support could open the gates for more naive user (such as me!) to grapple with the problems that I did and still do.

If C++ is "officially" endorsed by this change and works across ports, I think documentation should also be updated to reflect these pitfalls.

Chiefly there are two issues that have plagued me:

• malloc/new, including allocations that happen at runtime via static initialization (std::vector etc) - need to document that MICROPY_C_HEAP_SIZE > 0 (or similar) is required for C++ builds not to potentially explode/trounce gc_heap - I don't know if the Zephyr port or others have this concept
• C++ Stack unwinding/exception handling bloat - I've been using a hack in my CMakeLists.txt to stop our (already very overloaded) builds exploding with C++ bloat. I'd love more eyes on why this is and how to fix it - see: ports/rp2: Use nano.specs for C++ modules. #11143

Note: I also use a C++ module which redirects C++ malloc/free to MicroPython's GC_HEAP and allows me to track allocations. It's not ideal but it's a little more debuggable than MicroPython's "eh just throw C some space, it'll be fine" approach. You can see it in its full horror here: https://github.com/pimoroni/pimoroni-pico/blob/main/micropython/modules/cppmem/cppmem.cpp

I guess embedding MicroPython into something else is rather an about-face of my memory management problems, but I figure my painfully earned two cents would be better said than unsaid here.

need to document that MICROPY_C_HEAP_SIZE > 0 (or similar) is required for C+

Didn't know what that option was so found out it's for rp2 only, to be fair it says If a board uses malloc then it must set this to at least 4096. so that's pretty close already