Implement error interoperation (RFC 70)

[aturon]

This PR:

• Adds the error interoperation traits (Error and FromError) to a new module, std::error, as per RFC 70. Note that this module must live in std in order to refer to String.

  Note that, until multidispatch lands, the FromError trait cannot be
  usefully implemented outside of the blanket impl given here.

• Incorporates std::error::FromError into the try! macro.

• Implements Error for most existing error enumerations.

Closes#17747

[rust-highfive]

Warning

• These commits modify unsafe code. Please review it carefully!

[japaric]

Here, the return type is Option<&str>, but in the actual definition of the trait, the return type is Option<String>

[aturon]

@japaric Thanks, fixed.

[alexcrichton]

Do we have a path forward for unifying these other than allowing &Error to be casted to &Any?

[aturon]

That's the ideal path; I'm not sure how soon that's likely to happen.

Alternatively, we could probably define macros for this, but given visibility rules that seemed more pain than gain right now.

[aturon]

@alexcrichton fixed, thanks.

[alexcrichton]

I would actually expect inspection of errors to not fall under "an overwhelming majority of rust code does this", but rather just the tip of the stack is the one to inspect the error. Along those lines, I'm not sure I'd put this in the prelude to get access to the methods.

On the other hand, implementing the trait is always convenient if you don't have to import it (and it avoids the std::error::Error stutter).

The RFC doesn't look like it mentions any modifications to the prelude, so I'm curious, what was your rationale for placing this here?

[aturon]

I was just writing a comment to get your opinion about this. You're right, it wasn't mentioned in the RFC and for that reason alone probably shouldn't happen here.

I also worry about having the name Error show up in the prelude. So maybe an explicit import makes more sense.

(My rationale was just that you'd generally expect methods like description to be available on error types without needing to import a trait, but that's pretty weak sauce.)

[alexcrichton]

Do you think it may be best to wait for multidispatch to land before landing this? This is a pretty minimal change, so I don't think it's too susceptible to bitrot (ok on that front). I'd be more curious in going ahead and leveraging this trait throughout some examples in the stdlib/compiler/etc to give it a bit of usage and make sure the try! macro works as expected.

[aturon]

@alexcrichton Addressed comments, removed from prelude.

[aturon]

@alexcrichton Sure, we can wait to land this until multidispatch, and I can add tests/examples to docs.

[aturon]

Just an update: I've tried rolling this out with multidispatch now being snapshotted. However, there are some problems with type inference. @nikomatsakis is looking into it. We can't land this change to try! until that's resolved.

In general, also, the two blanket impls in the RFC conflict (the one that passes through a value unchanged, and the one that boxes it). If we had negative bounds, we could work around that. Instead, if you want to be able to get automatic boxing for a particular concrete error you'll have to write an impl for it.

[nikomatsakis]

cc #18019

[ghost]

@aturon Is this good to go after the next snapshot?

[alexcrichton]

cc #18259 for new snapshots

[aturon]

@alexcrichton I've updated with documentation and use of multidispatch. Building fine here. re-r?