Compiling with uVision seems very broken, I have tried on a LPC1768 and STM board and get thousands of errors
compile errors against mbed-os master
lpc1768 errors.txt
compiling with CLI works fine
5.13 compiles fine so it must be something fairly recent.
[ ] Question
[ ] Enhancement
[x] Bug
Can be reproduced with blinky? I'll run some tests tomorrow morning.
I can see the failures in the nightly http://mbed-os-ci.s3-website-eu-west-1.amazonaws.com/?prefix=jenkins-ci/ARMmbed/mbed-os/mbed-os-ci-nightly/artifacts/master/307/exporter/FAIL/uvision6/ 馃槶
cc @ARMmbed/mbed-os-test
@0xc0170 Blinky does the same.
Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-1608
@kjbracey-arm Reviewing the logs, this looks like related to the latest C++1x change.
See the above fail uvision6 logs. I fetched this one http://mbed-os-ci.s3-website-eu-west-1.amazonaws.com/?prefix=jenkins-ci/ARMmbed/mbed-os/mbed-os-ci-nightly/artifacts/master/307/exporter/FAIL/uvision6/NUCLEO_F412ZG/
./main.cpp(6): warning: In file included from...mbed-os\mbed.h(26): warning: In file included from...mbed-os/features\netsocket/nsapi.h(40): warning: In file included from...mbed-os/features\netsocket/UDPSocket.h(23): warning: In file included from...mbed-os/features\netsocket/InternetSocket.h(28): warning: In file included from...mbed-os/platform\mbed_atomic.h(884): warning: In file included from...mbed-os/platform/cxxsupport\mstd_type_traits(1088): error: no member named 'remove_cv_t' in namespace 'std'; did you mean 'remove_cv'?
using std::remove_cv_t;
~~~~~^~~~~~~~~~~
remove_cv
Only some targets failed in the nightly run, why not all? I was able to reproduce these errors, mbed export -m NUCLEO_F412ZG -i uvision6 and get lot of errors coming from traits file.
the uvision config has standard set gnu++11.
Yes, this is the issue described in the commit message of https://github.com/ARMmbed/mbed-os/commit/85041025cce45ac316e49212d3298ed21d8bb160 coming back and biting us.
Not sure how to make further progress here - we didn't manage to figure out fully what to do in #10427. I see there is 碌Vision 5.28a now - probably too much to hope it's received an update for this, but I'll check.
here's my options in 5.27


using GNU11 and C++14 seems to work, I've not thoroughly tested it though.
That immediately makes me wonder whether "C++14" is actually "gnu++14". I wouldn't have expected non-GNU mode to work - I thought our code base relied on GNU extensions.
I don't recall whether I actually double-checked the behaviour of that option at the time.
Aha, 5.28a has updated this, despite no mention in the release notes. That now has
"C++14", "gnu++14", "c++17 (community)", "gnu++17 (community)".
So I guess I can update to do a 5.28a-compatible export.
Aha, 5.28a has updated this, despite no mention in the release notes.
Not only us leave some important things out of release notes 馃檮
Most helpful comment
Aha, 5.28a has updated this, despite no mention in the release notes. That now has
"C++14", "gnu++14", "c++17 (community)", "gnu++17 (community)".
So I guess I can update to do a 5.28a-compatible export.