Update dependencies and fix builds

[rbtcollins]

No description provided.

[Stebalien]

What's the motivation for the new MSRV?

[rbtcollins]

Required to pass CI, without it there are a tonne of errors from use of unstabilised things. Coming up from crossbeam I think, via remove_dir_all's new parallel codepath on windows that I added in 0.6.

https://ci.appveyor.com/project/Stebalien/tempfile/builds/34838839

error[E0658]: use of unstable library feature 'maybe_uninit' (see issue #53491)
   --> C:\Users\appveyor\.cargo\registry\src\github.com-1ecc6299db9ec823\crossbeam-channel-0.4.3\src\flavors\array.rs:236:30
    |
236 |         slot.msg.get().write(MaybeUninit::new(msg));
    |                              ^^^^^^^^^^^^^^^^

[Stebalien]

Oh, I see. remove_dir_all has added a dependency on rayon. Making tempfile depend on something like rayon (and, more generally, starting threads) isn't an option.

[rbtcollins]

Oh, I see. remove_dir_all has added a dependency on rayon. Making tempfile depend on something like rayon (and, more generally, starting threads) isn't an option.

Ok; that wasn't clear.

I can't do this immediately, but:... - for rustups test suite we'd benefit from the performance improvements the remove_dir_all new codepath has being offered from tempfile as well. The primary reason to add that was for the toolchain component removal codepath - removing 10's of thousands of files serially was awfully slow.

We would also benefit from this parallel removal codepath in our test suites use of tempfile. What if the remove_dir_all parallelism was controlled via a feature, so tempfile could default to a conservative serial behaviour and serial dependencies, and users of tempfile could opt into faster behaviour, with the associated dependencies and complexity.

[rbtcollins]

Oh, and I've split out the master-fixing patch to #124 for you while we figure out what to do with remove_dir_all

[Stebalien]

We would also benefit from this parallel removal codepath in our test suites use of tempfile. What if the remove_dir_all parallelism was controlled via a feature, so tempfile could default to a conservative serial behaviour and serial dependencies, and users of tempfile could opt into faster behaviour, with the associated dependencies and complexity.

An opt-in feature works. My concern is that, by default at least, a temporary file library needs to be:

1. Light weight. I've even had requests to switch to lighter random libraries (ref: use SmallRng #119).
2. Predictable. I would not expect a temporary file library to spawn a bunch of threads. Honestly, I wouldn't expect a remove_dir_all function to do that either, I'm quite surprised this was enabled by default.

However, if the user explicitly opts in to removing files in parallel, that's their choice. I'd still prefer it if it were completely opt-in as anyone explicitly pulling in remove_dir_all (or some other library that depends on it) will be opted into this behavior even if they don't know about it, but I can live without that.