Policy on referring to rustc and other implementations

[ehuss]

I think there should be a policy on if and when it is acceptable to refer to rustc.

One option is to have a policy of never referring to it directly. However, I think that would result in a loss of information or assistance to Rust users. There are some gray areas where there is a close coupling between the language and rustc, and having a small tip or note can save some readers considerable time trying to find the relationships.

If we do allow it, I would recommend having a policy of avoiding it as much as possible, and only including it when there is a high level of relevance, and only as a side-note or tip.

See also #32 about referring to bugs.

There is also a closely related concern about whether or not anything should ever be "implementation specific", see #29.

Some examples from the Reference:

• rustc currently only allows the clippy and rustfmt tool attributes. It has not yet been decided if the tool attribute space should be extensible (and if so, how).
• The feature attribute links to the Unstable book.
• The description of user extensible cfg values mentions the way to do that is via rustc --cfg.
• The test cfg is set via rustc --test.
• Identifiers that start with an underscore are a convention to silence an unused warning in rustc.
• The dynamic and static C-runtime mentions rustc -C target-feature=+crt-static
• A note about the hazards of using #[inline] and the relationship to how rustc works.
• How target-features and target-cpu's are related via rustc options.
• Note about how you can find the available lints in the lint attribute docs.
• Note about what #[deprecated] does in rustc.
• Defaults for recursion_limit and type_length_limit.
• Mentions of certain hazards, like overflowing literals will generate a warning by rustc.
• Lots of documentation related to #[link] needs to cross-link with the rustc docs.
• The behavior of unwinding across nounwind abi uses an illegal instruction in rustc.
• An explanation of the requirement to use extern alloc; due to the way things work.
• How to write a proc-macro with Cargo (this shouldn't be in the spec, but there should be some place where we have that kind of documentation).
• Note about security concerns of proc-macros.
• Source files discuss filesystems specifically, but in theory there could be other ways that source is loaded. How rustc-specific is that?