Struct.field should resolve for intra-doc-links

[jyn514]

Found in #75432 (review). std::process::Child.stdout should resolve to the struct field, but instead gives a resolution error - you have to use Child::stdout instead. This is a break from the original RFC: https://github.com/rust-lang/rfcs/blob/68e17ace829e81239fe5020b7a6dbc22550b6d16/text/1946-intra-rustdoc-links.md#linking-to-fields

[jyn514]

Relevant code:

rust/src/librustdoc/passes/collect_intra_doc_links.rs

Line 256 in b11e2f2

// Try looking for methods and associated items.

rust/src/librustdoc/passes/collect_intra_doc_links.rs

Line 369 in b11e2f2

def.non_enum_variant()

We're treating enum variants and struct fields the same.

[Manishearth]

I'm actually kinda iffy on this, I prefer the current behavior and we get to avoid clashes with foo.com.

[jyn514]

Hmm, I think struct.field is more clear though since it's how you'd use it in rust code. But fortunately this only adds new behavior so it doesn't block stabilization, we can always choose to add it later.

[Manishearth]

Yeah I'm just worried about the possibilities of ambiguity. It was listed as an optional extension in the rfc and iirc this was part of why.

[GuillaumeGomez]

I'm not a big fan of this syntax but it's not a strong position either...

[camelid]

struct.field is less surprising which is good, but I definitely understand that it's difficult given the potential for clashes (especially with non-.com, .org, .net domains, e.g. .name). Maybe rustdoc could assume that it's an intra-doc link, and if it doesn't resolve then link to the equivalent domain? Unfortunately there's potential for minor breaking changes, although the Rust style is to have uppercase struct names and much of the time people link to lowercase domains, so maybe it wouldn't be too much of a clash.

[jyn514]

@camelid the concern I think is that there's no way to detect the ambiguity without reaching out and making network requests, which no one wants. So there's the potential that rustdoc could silently link to something other than what you intended, which is against the spirit of intra-doc links.

[jyn514]

and as a corrollary, rustdoc couldn't warn if the link failed to resolve, because it would have to assume it was a network link.

[camelid]

Yeah, it's too bad that there's not a solution that doesn't involve ambiguity and isn't surprising :(

[jyn514]

I think changes in this area should be a change to the intra-doc links RFC, not an implementation issue, so I'm going to close this.