rust/tests/rustdoc-ui/intra-doc/email-address-localhost.rs

// normalize-stderr-test: "nightly|beta|1\.[0-9][0-9]\.[0-9]" -> "$$CHANNEL"
// check-pass
#![deny(warnings)]

//! Email me at <hello@localhost>.

//! This should *not* warn: <hello@example.com>.
rustdoc: link to stable/beta docs consistently in documentation ## User-facing changes - Intra-doc links to primitives that currently go to rust-lang.org/nightly/std/primitive.x.html will start going to channel that rustdoc was built with. Nightly will continue going to /nightly; Beta will link to /beta; stable compilers will link to /1.52.1 (or whatever version they were built as). - Cross-crate links from std to core currently go to /nightly unconditionally. They will start going to /1.52.0 on stable channels (but remain the same on nightly channels). - Intra-crate links from std to std (or core to core) currently go to the same URL they are hosted at; they will continue to do so. Notably, this is different from everything else because it can preserve the distinction between /stable and /1.52.0 by using relative links. Note that "links" includes both intra-doc links and rustdoc's own automatically generated hyperlinks. ## Implementation changes - Update the testsuite to allow linking to /beta and /1.52.1 in docs - Use an html_root_url for the standard library that's dependent on the channel This avoids linking to nightly docs on stable. - Update rustdoc to use channel-dependent links for primitives from an unknown crate - Set DOC_RUST_LANG_ORG_CHANNEL from bootstrap to ensure it's in sync - Include doc.rust-lang.org in the channel 2021-05-04 22:36:33 -05:00			`// normalize-stderr-test: "nightly\|beta\|1\.[0-9][0-9]\.[0-9]" -> "$$CHANNEL"`
rustc_metadata: Store a flag telling whether an item may have doc links in its attributes This should be cheap on rustc side, but it's significant optimization for rustdoc that won't need to decode and process attributes unnecessarily 2022-04-16 15:49:37 -05:00			`// check-pass`
Don't report disambiguator error if link would have been ignored This prevents us from warning on links such as `<hello@example.com>`. Note that we still warn on links such as `<hello@localhost>` because they have no dots in them. However, the links will still work, even though a warning is reported. 2021-04-04 17:31:43 -05:00			`#![deny(warnings)]`

			`//! Email me at <hello@localhost>.`

			`//! This should not warn: <hello@example.com>.`