summaryrefslogtreecommitdiff
path: root/ports/unix/coveragecpp.cpp
AgeCommit message (Collapse)Author
2025-04-24unix/coveragecpp: Verify struct-initializing macros' C++-compatibility.stijn
Add code using all relevant macros to make sure they initialize structs correctly. Signed-off-by: stijn <stijn@ignitron.net>
2024-08-26unix/coveragecpp: Include all API headers in the C++ code.stijn
Make the CI builds compile the public API as C++ to catch accidental introductions of incompatible code. Signed-off-by: stijn <stijn@ignitron.net>
2024-03-07all: Remove the "STATIC" macro and just use "static" instead.Angus Gratton
The STATIC macro was introduced a very long time ago in commit d5df6cd44a433d6253a61cb0f987835fbc06b2de. The original reason for this was to have the option to define it to nothing so that all static functions become global functions and therefore visible to certain debug tools, so one could do function size comparison and other things. This STATIC feature is rarely (if ever) used. And with the use of LTO and heavy inline optimisation, analysing the size of individual functions when they are not static is not a good representation of the size of code when fully optimised. So the macro does not have much use and it's simpler to just remove it. Then you know exactly what it's doing. For example, newcomers don't have to learn what the STATIC macro is and why it exists. Reading the code is also less "loud" with a lowercase static. One other minor point in favour of removing it, is that it stops bugs with `STATIC inline`, which should always be `static inline`. Methodology for this commit was: 1) git ls-files | egrep '\.[ch]$' | \ xargs sed -Ei "s/(^| )STATIC($| )/\1static\2/" 2) Do some manual cleanup in the diff by searching for the word STATIC in comments and changing those back. 3) "git-grep STATIC docs/", manually fixed those cases. 4) "rg -t python STATIC", manually fixed codegen lines that used STATIC. This work was funded through GitHub Sponsors. Signed-off-by: Angus Gratton <angus@redyak.com.au>
2020-10-29esp32,unix: Support building C++ code.stijn
Support building .cpp files and linking them into the micropython executable in a way similar to how it is done for .c files. The main incentive here is to enable user C modules to use C++ files (which are put in SRC_MOD_CXX by py.mk) since the core itself does not utilize C++. However, to verify build functionality a unix overage test is added. The esp32 port already has CXXFLAGS so just add the user modules' flags to it. For the unix port use a copy of the CFLAGS but strip the ones which are not usable for C++.