Hi,
I have updated in the Arduino IDE 2.3.4 the Espressif ESP32 Core from 3.0.7 to 3.1.1.
With this I get
warning: use of 'auto' in parameter declaration only available with '-std=c++20' or '-fconcepts'
warning: range-based 'for' loops with initializer only available with '-std=c++20' or '-std=gnu++20' [-Wc++20-extensions]
Has the Cpp default setting been changed?
Can anyone comment on this?
I can't find a manual parameter in the platform.txt.
I don't think that your problem is relating to the Arduino Nano ESP32 and therefore have moved your topic to a more suitable location.
I can't help with the problem.
Espressif might know, its their code .....................
Maybe if we saw ALL the code that has been Auto Formatted and pasted in code tags.
Hi,
You don't need a code from me for that.
I made the following entry in platform.local.txt as a first workaround.
It also compiles with -std=gnu++23
compiler.cpp.flags=-MMD -c "@{compiler.sdk.path}/flags/cpp_flags" -std=gnu++20 -Wno-volatile {compiler.warning_flags} {compiler.optimization_flags} {compiler.common_werror_flags}
Hi @Doc_Arduino. It looks like the regression occurred here:
They were not kind enough to explain why they found it necessary to regress from C++23 to C++17 in order to "add Matter component as part of the libs".
It is in the flag file specified by the "@{compiler.sdk.path}/flags/cpp_flags" argument in the compilation command template.
When compiling for an ESP32 board, the file is here:
C:\Users\<username>\AppData\Local\Arduino15\packages\esp32\tools\esp32-arduino-libs\idf-release_v5.3-cfea4f7c-v1\esp32\flags\cpp_flags
When compiling for an ESP32-S3 board, the file is here:
C:\Users\<username>\AppData\Local\Arduino15\packages\esp32\tools\esp32-arduino-libs\idf-release_v5.3-cfea4f7c-v1\esp32s3\flags\cpp_flags
... and so on.
-mlongcalls -Wno-frame-address -fno-builtin-memcpy -fno-builtin-memset -fno-builtin-bzero -fno-builtin-stpcpy -fno-builtin-strncpy -ffunction-sections -fdata-sections -Wno-error=unused-function -Wno-error=unused-variable -Wno-error=unused-but-set-variable -Wno-error=deprecated-declarations -Wno-unused-parameter -Wno-sign-compare -Wno-enum-conversion -gdwarf-4 -ggdb -mdisable-hardware-atomics -freorder-blocks -Wwrite-strings -fstack-protector -fstrict-volatile-bitfields -fno-jump-tables -fno-tree-switch-conversion -Wno-error=uninitialized -Wno-error=maybe-uninitialized -Wno-format-nonliteral -Wno-missing-field-initializers -Wno-error=array-bounds -Wno-write-strings -std=gnu++2b -fexceptions -fno-rtti -std=gnu++17 -DCHIP_HAVE_CONFIG_H
(note the -std=gnu++17 flag, which overrides the prior -std=gnu++2b flag)
I think that is the best workaround.
Normally I would recommend using the compiler.cpp.extra_flags property to inject the additional flag into the compilation command instead of compiler.cpp.flags, as compiler.cpp.extra_flags was added to the platform for exactly this sort of use case. But unfortunately the developers of the "esp32" boards platform made the poor decision to place the {compiler.cpp.extra_flags} reference before the reference to compiler.cpp.flags in the compilation command template, which makes it impossible to use compiler.cpp.extra_flags to override flags from compiler.cpp.flags (since when a flag is used multiple times, the later occurrence overrides the prior one). So compiler.cpp.extra_flags can't be used.
Hi,
Thank you very much for all the information and explanation.
You are welcome. I'm glad if I was able to be of assistance.
Regards, Per
Hi,
Idea or question. Can the ESP32 developers correct the order of compiler flag integration with the next core package update?
Does the decision affect the Arduino or Espressif developers?
You can enter an issue on the GitHub.
Hi,
That is the point of my question - at the end.
I didn't know exactly who to ask the question to. 
Thanks.
You are welcome to participate. github Issue
Also, you must have changed something in the default settings? Since Arduino ESP32 Core Package 3.1.1, C++20 is no longer standard. With Core Package 3.0.7 I did not have to change anything in the compiler flags.
Since it is completely tangential to the subject of your issue report, I recommend instead submitting a dedicated issue about this. The relevant issue tracker would be here:
Thanks for the advice.
Hi,
I haven't dealt with this problem for a long time. I would like to do a complete PR and test it myself beforehand. I have a question about this. In which file(s) do I need to make changes to change the order of execution? Could I get some hints for this?
me-no-dev (GitHub) doesn't seem to have time.
Good news! They have since upgraded the standard from C++17 to C++20:
(gnu++2a is equivalent to c++20)
This means that, when using the latest version of the platform, it is no longer necessary to use the platform.local.txt workaround to force the use of C++20.
I responded on the discussion in the GitHub repo: