diff options
| author | kennytm <kennytm@gmail.com> | 2018-03-28 17:55:08 +0200 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2018-03-28 17:55:08 +0200 |
| commit | 0214304b5aa74fd6beaefb2474d6ba90ea423a43 (patch) | |
| tree | 30f4e1912b88ddc659b439c6856e8751c5324e4e /src/liballoc/string.rs | |
| parent | 4285e1cad486f089b047941f8b6560d3b4390c55 (diff) | |
| parent | 49fd71bea7bd3d8d11818503ca048227ffa1e758 (diff) | |
| download | rust-0214304b5aa74fd6beaefb2474d6ba90ea423a43.tar.gz rust-0214304b5aa74fd6beaefb2474d6ba90ea423a43.zip | |
Rollup merge of #49364 - wesleywiser:incr_handle_load_failure, r=michaelwoerister
[incremental] Don't panic if decoding the cache fails If the cached data can't be loaded from disk, just issue a warning to the user so they know why compilation is taking longer than usual but don't fail the entire compilation since we can recover by ignorning the on disk cache. In the same way, if the disk cache can't be deserialized (because it has been corrupted for some reason), report the issue as a warning and continue without failing the compilation. `Decodable::decode()` tends to panic with various errors like "entered unreachable code" or "index out of range" if the input data is corrupted. Work around this by catching panics from the `decode()` calls and continuing without the cached data. Fixes #48847
Diffstat (limited to 'src/liballoc/string.rs')
0 files changed, 0 insertions, 0 deletions
