Change:
`"mips"`, `"powerpc"`, `"arm"`, or `"aarch64"`. * `target_endian = "..."`. Endianness of the target CPU, either `"little"` or `"big"`. <ins> * `target_env = ".."` - an 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. </ins> * `target_family = "..."`. Operating system family of the target, e. g. `"unix"` or `"windows"`. The value of this configuration option is defined as a configuration itself, like `unix` or `windows`.

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.