Change:
`panic!` is a macro, similar to `println!()` that we’ve already seen. Unlike `println!()`, `panic!()` causes the current thread of execution to crash with <del> the given message. </del> <ins> the given message. Because this function will cause a crash, it will never return, and so it has the type ‘`!`’, which is read ‘diverges’. </ins> <del> Because this function will cause a crash, it will never return, and so it has the type ‘`!`’, which is read ‘diverges’. A diverging function can be used as any type: </del> <ins> If you add a main function that calls `diverges()` and run it, you’ll get some output that looks like this: ```text thread ‘<main>’ panicked at ‘This function never returns!’, hello.rs:2 ``` If you want more information, you can get a backtrace by setting the `RUST_BACKTRACE` environment variable: ```text $ RUST_BACKTRACE=1 ./diverges thread '<main>' panicked at 'This function never returns!', hello.rs:2 stack backtrace: 1:     0x7f402773a829 - sys::backtrace::write::h0942de78b6c02817K8r 2:     0x7f402773d7fc - panicking::on_panic::h3f23f9d0b5f4c91bu9w 3:     0x7f402773960e - rt::unwind::begin_unwind_inner::h2844b8c5e81e79558Bw 4:     0x7f4027738893 - rt::unwind::begin_unwind::h4375279447423903650 5:     0x7f4027738809 - diverges::h2266b4c4b850236beaa 6:     0x7f40277389e5 - main::h19bb1149c2f00ecfBaa 7:     0x7f402773f514 - rt::unwind::try::try_fn::h13186883479104382231 8:     0x7f402773d1d8 - __rust_try 9:     0x7f402773f201 - rt::lang_start::ha172a3ce74bb453aK5w 10:     0x7f4027738a19 - main 11:     0x7f402694ab44 - __libc_start_main 12:     0x7f40277386c8 - <unknown> 13:                0x0 - <unknown> ``` `RUST_BACKTRACE` also works with Cargo’s `run` command: ```text $ RUST_BACKTRACE=1 cargo run Running `target/debug/diverges` thread '<main>' panicked at 'This function never returns!', hello.rs:2 stack backtrace: 1:     0x7f402773a829 - sys::backtrace::write::h0942de78b6c02817K8r 2:     0x7f402773d7fc - panicking::on_panic::h3f23f9d0b5f4c91bu9w 3:     0x7f402773960e - rt::unwind::begin_unwind_inner::h2844b8c5e81e79558Bw 4:     0x7f4027738893 - rt::unwind::begin_unwind::h4375279447423903650 5:     0x7f4027738809 - diverges::h2266b4c4b850236beaa 6:     0x7f40277389e5 - main::h19bb1149c2f00ecfBaa 7:     0x7f402773f514 - rt::unwind::try::try_fn::h13186883479104382231 8:     0x7f402773d1d8 - __rust_try 9:     0x7f402773f201 - rt::lang_start::ha172a3ce74bb453aK5w 10:     0x7f4027738a19 - main 11:     0x7f402694ab44 - __libc_start_main 12:     0x7f40277386c8 - <unknown> 13:                0x0 - <unknown> ``` A diverging function can be used as any type: </ins> ```should_panic # fn diverges() -> ! {

Discussion:
Now, run the following You get the following error: A simple fix to this is to add at the beginning of , but that should not be unnecessary. Reproduces on nightly.
This is currently working as intended, the flags only work for specifying the immediate set of dependencies (those listed in ), and transitive dependencies must be found through paths. You can use to make sure that only transitive dependencies are found in those paths.
If that is the intended behavior, then please reopen this issue and mark it as a documentation problem. I cannot find where this distinction is explained. This section of would imply that: / are for use with native libraries only, not even mentioning the KIND. by itself will not actually search for crates in that directory. should be used for telling rust where to locate any crate and is an intuitive solution to errors like For reference, how do you thus indicate to rust where to locate a crate whose filename does not follow the pattern?
Yeah seems reasonable to leave open as a docs issue. Not sure exhaustive documentation should go into the message but the man page could certainly be up. That... can't actually be done I don't think. The only way the compiler looks for transitive dependencies is via where is the name of the crate.

It'd be helpful for people who want make documentation pull requests that aren't just typo's to be able to build the documentation, and preview it themselves. Adding a "How To" about how documentation for the main repo should be built, would be helpful.
Building the documentation should be as simple as , which however requires a full rust build which can take some time. Once a full build has been completed should allow you to build the documentation without rebuilding the whole compiler. I don't think there currently is a way to build the docs without building the compiler. Edit: Running gives a very basic introduction to rust's build system.
You can run on any crate, so I often or whatever I'm working on. It works on markdown files too.
It's worth noting that you need a (very) recent version of rustdoc to create docs from the source in master HEAD. It's often the case that even a nightly rustdoc is not new enough (although maybe it is, if you pass or something...).
Huh, I've never ran into that as an issue.

Title says it all. cc
This was recently for MUSL/MSVC, and for sake the docs would probably look something like: - a cfg option provided by the compiler by default describing the runtime environment of the target platform. Some examples of this are "musl" for builds targeting the MUSL libc implementation, "msvc" for Windows builds targeting MSVC, and "gnu" frequently the rest of the time. This option may also be blank on some platforms.

Currently, the only documentation of the rules for object safety I could find is in . However, this should also become part of the official documentation, for example .
It is currently defined in but having it in the book would be nice too.