Add ERROR

Co-Authored-By: Mazdak Farrokhzad <[email protected]>

Have tidy ensure that we document all `unsafe` blocks in libcore

cc @rust-lang/libs

I documented a few and added ignore flags on the other files. We can incrementally document the files, but won't regress any files this way.

…, r=kinnison

[rustdoc] add sub settings

This PR is to give a finer control over what types are automatically expanded or not as well as the possibility to add sub-settings in the settings page.

![Screenshot from 2019-09-23 00-46-14](https://user-images.githubusercontent.com/3050060/65395521-15aff300-dd9c-11e9-9437-429ca347d455.png)

r? @Mark-Simulacrum

Stabilize --extern flag without a path.

This stabilizes the `--extern` flag without a path, implemented in rust-lang#54116.

This flag is used to add a crate that may be found in the search path to the extern prelude. The intent of stabilizing this now is to change Cargo to emit this flag for `proc_macro` when building a proc-macro crate. This will allow the ability to elide `extern crate proc_macro;` for proc-macros, one of the few places where it is still necessary.

It is intended that Cargo may also use this flag for other cases in the future as part of the [std-aware work](https://github.com/rust-lang/wg-cargo-std-aware/). There will likely be some kind of syntax where users may declare dependencies on other crates (such as `alloc`), and Cargo will use this flag so that they may be used like any other crate. At this time there are no short-term plans to use it for anything other than proc-macro.

This will not help for non-proc-macro crates that use `proc_macro`, which I believe is not too common?

An alternate approach for proc-macro is to use the `meta` crate, but from my inquiries there doesn't appear to be anyone interested in pushing that forward. The `meta` crate also doesn't help with things like `alloc` or `test`.

cc rust-lang#57288

consistent handling of missing sysroot spans

Due to rust-lang#53081, sysroot spans (pointing to code in libcore/libstd/...) fails to print on some x86 runners. This consolidates the ignore directives for that and references the relevant issue.

I also did that for the generated derive-error-span tests -- but there the script and the tests were not entirely in sync any more since rust-lang#64151. Cc @estebank @varkor

invalid_value lint: fix help text

Now that we also warn about `MaybUninit::uninit().assume_init()`, just telling people "use `MaybeUninit`" isn't always sufficient. And anyway this seems like an important enough point to mention it here.