Destabilize the Error::type_id function

[alexcrichton]

This commit destabilizes the Error::type_id function in the standard library.
This does so by effectively reverting #58048, restoring the #[unstable]
attribute. The security mailing list has recently been notified of a
vulnerability relating to the stabilization of this function. First stabilized
in Rust 1.34.0, a stable function here allows users to implement a custom
return value for this function:

struct MyType;
impl Error for MyType {
fn type_id(&self) -> TypeId {
// Enable safe casting to `String` by accident.
TypeId::of::<String>()
}
}

This, when combined with the Error::downcast family of functions, allows
safely casting a type to any other type, clearly a memory safety issue! A
formal announcement has been made to the security mailing list as well as the blog

This commit simply destabilizes the Error::type_id which, although breaking
for users since Rust 1.34.0, is hoped to have little impact and has been deemed
sufficient to mitigate this issue for the stable channel. The long-term fate of
the Error::type_id API will be discussed at #60784.

[rust-highfive]

r? @KodrAus

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

r? @pietroalbini

[emilyalbini]

@bors r+ p=500

[bors]

📌 Commit 3db667a has been approved by pietroalbini

[strega-nil]

Is there something wrong with making it an unsafe trait?

[sfackler]

@ubsan Making the Error trait unsafe would break literally every error type in the ecosystem.

[strega-nil]

@sfackler oh, I see, right; you want it to only be unsafe to write the function

[strega-nil]

So it'd be better to have something on the order of

unsafetraitTypeInfo{fntype_id(&self) -> TypeId;}impl<T: ?Sized>TypeInfoforT{fntype_id(&self) -> TypeId{TypeId::of::<Self>()}}traitError:TypeInfo{}

[bors]

⌛ Testing commit 3db667a with merge 291ea7569bf6e6aa63b7312c51c7489632f7bb63...

[bors]

💔 Test failed - checks-travis

[rust-highfive]

The job arm-android of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[01:49:34] test string::test_str_clear ... ok
[01:49:34] test string::test_str_truncate ... ok
[01:49:34] test string::test_str_truncate_invalid_len ... ok
[01:49:34] test string::test_str_truncate_split_codepoint ... ok
[01:49:34] died due to signal 11
[01:49:34] [01:49:34] [01:49:34] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "test" "--target" "arm-linux-androideabi" "-j" "4" "--release" "--locked" "--color" "always" "--features" "panic-unwind backtrace" "--manifest-path" "/checkout/src/libstd/Cargo.toml" "-p" "alloc" "--"
[01:49:34] expected success, got: exit code: 3
---
travis_time:end:08504cb5:start=1557796268113303392,finish=1557796268127153888,duration=13850496
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:0234c5fe
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:294798ee
travis_time:start:294798ee
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:02e1fc00
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

[sugar700]

The proposed TypeInfo trait doesn't have to be unsafe, as it cannot be implemented (similarly to how std::any::Any is a safe trait because it's not possible to provide a manual implementation). That said, for TypeInfo to be usable in such a manner, TypeInfo has to be implemented for all types while the type_id would be only available for Self: 'static (and really, if it could be done without doing this, we could as well use std::any::Any instead of creating a new TypeInfo trait).

use std::any::TypeId;use std::fmt::{Debug,Display};traitTypeInfo{fntype_id(&self) -> TypeIdwhereSelf:'static;}impl<T: ?Sized>TypeInfoforT{fntype_id(&self) -> TypeIdwhereT:'static,{TypeId::of::<Self>()}}traitError:Debug + Display + TypeInfo{fndescription(&self) -> &str{"description() is deprecated; use Display"}fncause(&self) -> Option<&dynError>{self.source()}fnsource(&self) -> Option<&(dynError + 'static)>{None}}

Also, one thing I feel like Rust is missing is being able to declare a trait method as unsafe to implement. std::io::Read::initializer sorta tries to do this by marking the method as unsafe, but the method isn't unsafe, implementing it with non-default-implementation is, so it's not quite accurate.

[emilyalbini]

@bors retry

@xfix can we keep the discussion in #60784? Thanks ❤️

[bors]

⌛ Testing commit 3db667a with merge 4423351...

[bors]

💥 Test timed out

[emilyalbini]

@bors retry

[bors]

⌛ Testing commit 3db667a with merge f59c71e...

[bors]

☀️ Test successful - checks-travis, status-appveyor
Approved by: pietroalbini
Pushing f59c71e to master...