Audit `color-eyre` and its dependencies

[Shnatsel]

color-eyre is a popular crate for error handling, with over 1 million downloads, and the eyre itself has over 3 million downloads.

It relies on a surprising amount of unsafe code, even with default-features = false:

0/0        0/0          0/0    0/0     0/0      ❓ └── color-eyre 0.6.1
7/22       218/779      2/6    0/0     2/5      ☢️      ├── backtrace 0.3.64
0/0        11/26        0/0    0/0     0/0      ☢️      │   ├── addr2line 0.17.0
0/0        29/48        1/3    1/1     0/0      ☢️      │   │   ├── gimli 0.26.1
0/0        24/26        0/0    1/1     0/0      ☢️      │   │   ├── object 0.27.1
20/37      1320/2140    0/0    0/0     16/16    ☢️      │   │   │   └── memchr 2.4.1
0/20       12/327       0/2    0/0     2/30     ☢️      │   │   │       └── libc 0.2.119
0/0        0/0          0/0    0/0     0/0      ❓     │   │   └── rustc-demangle 0.1.21
0/0        0/0          0/0    0/0     0/0      ❓     │   ├── cfg-if 1.0.0
0/20       12/327       0/2    0/0     2/30     ☢️      │   ├── libc 0.2.119
0/0        0/0          0/0    0/0     0/0      🔒     │   ├── miniz_oxide 0.4.4
0/0        0/0          0/0    0/0     0/0      🔒     │   │   └── adler 1.0.2
0/0        24/26        0/0    1/1     0/0      ☢️      │   ├── object 0.27.1
0/0        0/0          0/0    0/0     0/0      ❓     │   └── rustc-demangle 0.1.21
10/10      220/220      0/0    0/0     1/1      ☢️      ├── eyre 0.6.7
0/0        0/0          0/0    0/0     0/0      ❓     │   ├── indenter 0.3.3
1/1        74/93        4/6    0/0     2/3      ☢️      │   └── once_cell 1.10.0
0/0        0/0          0/0    0/0     0/0      ❓     ├── indenter 0.3.3
1/1        74/93        4/6    0/0     2/3      ☢️      ├── once_cell 1.10.0
0/0        16/16        0/0    0/0     0/0      ☢️      └── owo-colors 3.2.0

A number of dependencies look like they shouldn't need custom unsafe code - such as owo-colors, object, gimli, as well as eyre itself.

It would be nice to remove unsafe code where reasonable.

I haven't looked at the details yet, but the object and gimli crates might be possible to switch to bytemuck instead of custom code, and owo-colors should not need any unsafe at all.

[WaffleLapkin]

It's weird that owo-colors has unsafe given this line from the readme:

No allocations, unsafe, or dependencies required because embedded systems deserve to be pretty too uwu.

The only place I've found unsafe in there is used to convert &[u8] to &str in a const. Given that std::str::from_utf8 is const unstable I don't think that there is a simple way to remove this unsafe.

[danielhenrymantilla]

FWIW, it could use str::from_utf8_unchecked, which would already be a bit less unsafe than a transmute (one oughtn not to transmute repr(Rust) entities, even just the wide-pointer ones). Also, there could be a smaller const_concat!-like dependency in charge of doing the unsafe to perform the concatenation.

• In this case, for instance, something like a crate exposing a AsciiU8 const-constructible type, and a [AsciiU8] -> str unsafe-using conversion which would be trivial to review as sound 🤔

[yaahc]

I haven't looked at the details yet, but the object and gimli crates might be possible to switch to bytemuck instead of custom code, and owo-colors should not need any unsafe at all.

This would have to be done in backtrace itself, not as part of color-eyre, also, std::backtrace::Backtrace itself also depends on backtrace-rs^1 and I believe enables gimli as well^3 so I'd recommend treating that as it's own independent effort rather than as part of a review of color-eyre.

Eyre has a known issue^4 and needs a fix and I've had a couple people say they're willing to do the fix but so far that hasn't materialized, so that would be the best starting point imo, and I imagine the lions share of further improvements that could be made would also need to happen in eyre itself rather than any of the other deps. I'm happy to help explain any of the unsafe that is currently present. I imagine the biggest simplification would be to rework the special downcasting support^5 we inherited from anyhow. It may also be possible to rip out the custom thin pointer logic we have and replace it with https://doc.rust-lang.org/nightly/std/boxed/struct.ThinBox.html.