The only real use for thread names is so that they appear in panic messages. However, names set by this API won't appear in panic messages because we aren't `std::thread` and therefore don't have access to `sys_common::thread_info` where libstd stashes its thread names. So without that functionality, there's not much of a reason to have thread names at all.
Both our implementation of std and ctru-rs depend on the libc crate (or rather, ctru-rs depends on ctru-sys which depends on libc). This means that libc ends up both in the sysroot assembled by Xargo, as well as being built as a regular dependency for ctru-rs. However, it seems that when cargo/rustc tries to link the libc crate to ctru-rs, it first searches in the sysroot and links in the copy that it finds there, rather than the one specified in ctru-rs's Cargo.toml.
rust-lang's rustbuild system does some trickery with crate metadata to avoid this sort of name collision between the sysroot and user deps, but xargo does not (yet) do something similar. And since rustc now enforces that linking to any crate from the sysroot is an unstable operation, the result is a rather cryptic compiler error.
Fortunately we can work around this by simply tagging ctru-rs with #![feature(rustc_private)], but it shouldn't be regarded as a long-term fix
I'd thought that it would be necessary for implementing features such as the std::os::raw types in ctr-std, but I do not believe that that is the case.
AzureMarker