Improve compile times by delegating to non-polymorphic functions about fs-err

[andrewhickman]

Thanks for the suggestion! I suspect the addition of the Into<PathBuf> bound on everything means we can't be as good as the standard library on this (since we typically only want to call .into() in the error path), but there are probably some places we can improve.

[matklad]

I don't quite see why Into<PathBuf> is required though? I would expect that monomorphic private functions would just take &Path as an argument, and call .to_path_buf() on the error path. I don't think this meaningfully changes the allocations -- if the caller has only &Path, then the behavior is the same. If the caller has a PathBuf and is ready to sacrifice it to call an fs method, then, yeah, we do an extra allocation on the error path, but:

• this is a cold path
• given that we require an owned path in this case, this amortizises to the same number of allocations. Ie, you can't construct a loop where the number of allocations goes from O(1) to O(N)

[andrewhickman]

Good points. I believe constructing a custom io::Error already does two allocations so cloning the path as well is probably OK.

[Emerentius]

The change is straightforward except for File constructors and the three functions which construct a File internally (see #31). Those need a PathBuf even on the hot path. Is the performance hit of always cloning big enough that it should be avoided?