Out of date vendored STL

[mikepurvis]

There are another round of fixes needed for the out of date STL shipped by stm32plus here: https://github.com/andysworkshop/stm32plus/tree/master/lib/include/stl

gnuarm 7-2018-q2-6 complains, for example:

[ 92%] Building CXX object CMakeFiles/[...]/src/hardware/system_hardware.cpp.obj
In file included from [...]/include/hardware/system_hardware_revision.h:43:0,
                 from [...]/src/hardware/system_hardware_revision.cpp:12:
/usr/local/arm-none-eabi/include/stm32plus-040100/stl/string: In instantiation of 'std::basic_string<_CharT, _Traits, _Alloc>& std::basic_string<_CharT, _Traits, _Alloc>::append(_InputIter, _InputIter) [with _InputIter = const char*; _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]':
/usr/local/arm-none-eabi/include/stm32plus-040100/stl/string:1317:11:   required from 'std::basic_string<_CharT, _Traits, _Alloc>& std::basic_string<_CharT, _Traits, _Alloc>::assign(const _CharT*, const _CharT*) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]'
/usr/local/arm-none-eabi/include/stm32plus-040100/stl/string:366:13:   required from 'std::basic_string<_CharT, _Traits, _Alloc>& std::basic_string<_CharT, _Traits, _Alloc>::operator=(const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]'
[...]/src/hardware/system_hardware_revision.cpp:44:25:   required from here
/usr/local/arm-none-eabi/include/stm32plus-040100/stl/string:570:30: error: no matching function for call to 'std::basic_string<char>::_M_append_dispatch(const char*&, const char*&, _Integral)'
     return _M_append_dispatch(__first, __last, _Integral());

However, other than slist (renamed to forward_list), I believe the library mostly works with a modern STL like the one in the libstdc++-arm-none-eabi-newlib package (version 15:7-2018-q2-5+12 in Focal). Would we entertain stripping out the vendored STL in favour of recommending an external one?

---

Looks like some effort was made to support external STL implementations with be510ee, though there are other slist usages (especially in net) which need to be similarly patched.

In all, the changes needed for me (since newlib does indeed ship an ext/slist header) were:

• Patching all other uses of slist to match be510ee.
• Deleting the contents of lib/include/util/StdExt.h.
• In the root construct file, patching lib/include/stl out of CPPPATH, and -DEXT_SLIST into CCFLAGS.

I think there are basically three main paths forward here:

1. Support newlib only (probably as of 6.3.1, the version in Ubuntu Bionic), excising lib/include/stl from the repo. At some point, port the internal slist uses over to use the standard forward_list.
2. Improve on the current dual-support story, probably with an internal compatibility header for slist to smooth over the type naming and import difference (and maybe a better ifdef name than EXT_SLIST).
3. Don't explicitly support newlib, and continue to patch the vendored SGI STL to work with newer compilers. Main downsides are just the ongoing whack-a-mole + potential compat issues in projects that use other libs linking to the standard toolchain.

[mikepurvis]

Here's the diff that corresponds to option 1:

master...mikepurvis:no-stl

This is what we'll be moving forward with for now on our end, but I'm open to the discussion resolving in whatever way it does.