The reverse conversion unfortunately causes unexpected errors like:
```
error[E0277]: the trait bound `!: std::convert::From<()>` is not satisfied
--> src/librustc_metadata/encoder.rs:105:9
|
105 | self.emit_usize(seq.len)?;
| ^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::convert::From<()>` is not implemented for `!`
|
= help: the following implementations were found:
<! as std::convert::From<std::convert::Infallible>>
= note: the trait is implemented for `()`. Possibly this error has been caused by changes to Rust's type-inference algorithm (see: https://github.com/rust-lang/rust/issues/48950 for more info). Consider whether you meant to use the type `()` here instead.
= note: required by `std::convert::From::from`
```
I don’t understand why this error happens.
If I’m reading the code correctly the return types of `emit_usize`
and of the method that contains line 105 are both `Result<(), !>`,
so the expansion of the `?` operator should involve `!: From<!>`,
not `From<()>`.
Is this a type inference bug?
Cosmetic improvements to doc comments
This has been factored out from https://github.com/rust-lang/rust/pull/58036 to only include changes to documentation comments (throughout the rustc codebase).
r? @steveklabnik
Once you're happy with this, maybe we could get it through with r=1, so it doesn't constantly get invalidated? (I'm not sure this will be an issue, but just in case...) Anyway, thanks for your advice so far!
This is not really significant, accept or reject as you wish. I
just want to make sure I understand how the PR process works and
I'm doing it right before doing a bigger one for #33417.
Change bounds on `TryFrom` blanket impl to use `Into` instead of `From`
This is from this [comment](https://github.com/rust-lang/rust/issues/33417#issuecomment-447111156) I made.
This will expand the impls available for `TryFrom` and `TryInto`, without losing anything in the process.
This commit replaces many usages of `File::open` and reading or writing
with `fs::read_to_string`, `fs::read` and `fs::write`. This reduces code
complexity, and will improve performance for most reads, since the
functions allocate the buffer to be the size of the file.
I believe that this commit will not impact behavior in any way, so some
matches will check the error kind in case the file was not valid UTF-8.
Some of these cases may not actually care about the error.
