CubeMX always creates a C file. FreeRTOS is a C program, the HAL drivers (and LL drivers) are C programs. I'll bet all of the provided routines are C.
CubeMX is C.
Renaming main.c to main.cpp does work, but you eventually have to automate it to keep from getting mixed up with the latest version (.c) and the version you tweaked (.cpp). Note also that CubeMX has to read your .c file to keep the user sections.
I'll disagree that calling the C++ from C is an ugly hack. Once done properly (at least through a bridging call), you don't have to worry about it ever again. Period. Your main.c stays main.c, your application code is in C++, and barring a few hiccups (or hiccoughs) with FreeRTOS and some other support routines, you're done.
I doubt that the support software will ever go to C++, there's a lot out there. FreeRTOS, because of design philosophy, may (likely will) never go to C++. You can write the equivalent of FreeRTOS (limited or otherwise) in C++, so that's not the problem.
I have a C++ project with graphics, FreeRTOS, SD cards, HAL drivers, touchscreen, SPI, I2C, serial, NRF networking. As much of it is C++ as possible, but FATFS, FreeRTOS, hal drivers, they're all C. It still works.
I don't think the situation will change with respect to C, C++. I do think that a good solution (at least to the main.c problem) is to allow CubeMX to make changes to main.cpp if it can't find main.c. It could be a special configuration box with all sorts of lawyer induced warnings but it would save the renaming problem.
