Change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: rustdoc parses the link as an email address and renders it as a mailto: link. Instead, this happened: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --(from a GitHub Actions run, the latest nightly won't install on my Arch box due to broken components)
This turned out to be a bug in my docs; I didn't intend for this to be rendered as a link, but I was hoping for a better error message.
I think this PR introduced this new behavior:
This is weird - rustdoc should be ignoring any link that has in it:
Ah I see the issue - should only be reported if the link isn't ignored. do you have time to fix it? It should be as simple as adding the same check here:
Assigning and removing as in the prioritization working group. label: +P-medium -I-prioritize
can part of the fix here be to improve the error message? "Unknown disambiguator" doesn't tell me much about what is wrong or how to fix it.
I'm confused. After there won't be an error message, because the link shouldn't have been treated as an intra-doc link in the first place. Are you asking for a lint that warns about docs that will be rendered as mailto: links? I'm not sure how useful that is, mailto: links are normal and reasonable to write.
based on the UI tests that are checked in, if I actually intend to use an intradoc link with a disambiguator and fat finger as , the error message is not super friendly.
Hmm, what would you like to see instead? There's quite a few valid disambiguators, I'm not sure it makes sense to list them all. Maybe we could add a header to the disambiguator section of and link there?
Ideally I'd like to see a suggestion to use a disambiguator that corresponds to an item that is currently in scope or otherwise resolvable via the path after the invalid disambiguator.
Hmm, that seems useful, although I think it should be a separate issue. Maybe we could try resolving without a disambiguator and see if there are any results? That would need a pretty significant overhaul of how it works currently, right now all the errors are emitted eagerly which would end up with a lot more verbose output that might not be relevant. What would you expect to see if the link isn't valid even without the disambiguator?
I think an extra to more docs on intradoc link disambiguators would be helpful per your previous comment. The idea to attempt to resolve items for all invalid disambiguators feels similar to the Ruby CLI and REPL's "did you mean" feature, which I find quite useful.
The PR improving the diagnostics is being reverted in , reopening the issue.
I don't think this is still a regression; the diagnostics improvement was not part of the fix for the regression. (The regression was fixed in .)
Yeah, never had a tracking issue.
was relanded in

Discussion:
Ok(Some((d, path))) => (path.trim(), Some(d)), Ok(None) => (link.trim(), None), Err((err_msg, relative_range)) => { <del> let disambiguator_range = (no_backticks_range.start + relative_range.start) ..(no_backticks_range.start + relative_range.end); disambiguator_error(self.cx, &item, dox, disambiguator_range, &err_msg); </del> <ins> if !should_ignore_link_with_disambiguators(link) { // Only report error if we would not have ignored this link. // See issue #83859. let disambiguator_range = (no_backticks_range.start + relative_range.start) ..(no_backticks_range.start + relative_range.end); disambiguator_error(self.cx, &item, dox, disambiguator_range, &err_msg); } </ins> return None; } }; <del> if path_str.contains(|ch: char| !(ch.is_alphanumeric() || ":_<>, !*&;".contains(ch))) { </del> <ins> if should_ignore_link(path_str) { </ins> return None; }

..(ori_link.range.start + before_second_backtick_group) } <ins> /// Returns true if we should ignore `link` due to it being unlikely /// that it is an intra-doc link. `link` should still have disambiguators /// if there were any. /// /// The difference between this and [`should_ignore_link()`] is that this /// check should only be used on links that still have disambiguators. fn should_ignore_link_with_disambiguators(link: &str) -> bool { link.contains(|ch: char| !(ch.is_alphanumeric() || ":_<>, !*&;@()".contains(ch))) } /// Returns true if we should ignore `path_str` due to it being unlikely /// that it is an intra-doc link. fn should_ignore_link(path_str: &str) -> bool { path_str.contains(|ch: char| !(ch.is_alphanumeric() || ":_<>, !*&;".contains(ch))) } </ins> #[derive(Copy, Clone, Debug, PartialEq, Eq, Hash)] /// Disambiguators for a link. crate enum Disambiguator {

<ins> #![deny(warnings)] //! Email me at <hello@localhost>. //~^ ERROR unknown disambiguator `hello` //! This should *not* warn: <hello@example.com>. </ins>

<ins> error: unknown disambiguator `hello` --> $DIR/email-address-localhost.rs:3:18 | LL | //! Email me at <hello@localhost>. |                  ^^^^^ | note: the lint level is defined here --> $DIR/email-address-localhost.rs:1:9 | LL | #![deny(warnings)] |         ^^^^^^^^ = note: `#[deny(rustdoc::broken_intra_doc_links)]` implied by `#[deny(warnings)]` error: aborting due to previous error </ins>

<ins> //! Email me at <hello@example.com>. //! Email me at <hello-world@example.com>. //! Email me at <hello@localhost> (this warns but will still become a link). // @has email_address/index.html '//a[@href="mailto:hello@example.com"]' 'hello@example.com' // @has email_address/index.html '//a[@href="mailto:hello-world@example.com"]' 'hello-world@example.com' // @has email_address/index.html '//a[@href="mailto:hello@localhost"]' 'hello@localhost' </ins>