Description
The rustup installation system has a transactional system that is only partially transactional.
It isn't concurrent operation safe (see #988 ), but it also isn't able to recover from lost writes to the components file for other reasons such as IO errors or crashes of rustup itself.
These failures show up as conflicts during the next install - e.g.
error: failed to install component: 'rustc-x86_64-apple-darwin', detected conflict: '"lib/rustlib/etc/gdb_load_rust_pretty_printers.py"'
The solution is to remove the entire toolchain and reinstall it with all the desired components. There is no need to uninstall all of rustup, but there is also no lesser solution.
We do not yet have a design for solving this systematically, but see #988 for solving the concurrent-operation safety aspect, which is the most common cause of problems (e.g. for users of IDEs and CI systems that do not serialise their operations internally). We are considering an eventually-consistent model which would address this, but work has not yet started on it.