nordic-dev.net/rust
nordic-dev.net/rust
2
0
Fork 0
mirror of https://github.com/rust-lang/rust.git synced 2025-02-24 21:05:12 +00:00
Code Issues Packages Projects Releases Wiki Activity

Rollup merge of #92075 - jyn514:resolve-cleanup, r=camelid

Browse Source 
rustdoc: Only special case struct fields for intra-doc links, not enum variants

Variants are already handled by `resolve_str_path_error`, rustdoc doesn't need to consider them separately. Thanks `@camelid` for catching this!

Eventually I'd like to fix the "combine this with `variant_field`" comment but that needs `resolve_field` to take a `ty_res` parameter to avoid it being super hacky (cc https://github.com/rust-lang/rust/issues/83761#issuecomment-813026026).

r? `@camelid`
This commit is contained in:
Matthias Krüger 2021-12-29 10:17:08 +01:00 committed by GitHub
commit e31314307f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 25 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

41
src/librustdoc/passes/collect_intra_doc_links.rs
View File

@ -684,27 +684,36 @@ impl<'a, 'tcx> LinkCollector<'a, 'tcx> {
if ns != Namespace::ValueNS { if ns != Namespace::ValueNS {
return None; return None;
} }
debug!("looking for variants or fields named {} for {:?}", item_name, did); debug!("looking for fields named {} for {:?}", item_name, did);
// FIXME: this doesn't really belong in `associated_item` (maybe `variant_field` is better?) // FIXME: this doesn't really belong in `associated_item` (maybe `variant_field` is better?)
// NOTE: it's different from variant_field because it resolves fields and variants, // NOTE: it's different from variant_field because it only resolves struct fields,
// not variant fields (2 path segments, not 3). // not variant fields (2 path segments, not 3).
//
// We need to handle struct (and union) fields in this code because
// syntactically their paths are identical to associated item paths:
// `module::Type::field` and `module::Type::Assoc`.
//
// On the other hand, variant fields can't be mistaken for associated
// items because they look like this: `module::Type::Variant::field`.
//
// Variants themselves don't need to be handled here, even though
// they also look like associated items (`module::Type::Variant`),
// because they are real Rust syntax (unlike the intra-doc links
// field syntax) and are handled by the compiler's resolver.
let def = match tcx.type_of(did).kind() { let def = match tcx.type_of(did).kind() {
ty::Adt(def, _) => def, ty::Adt(def, _) if !def.is_enum() => def,
_ => return None, _ => return None,
}; };
let field = if def.is_enum() { let field = def
def.all_fields().find(|item| item.ident.name == item_name) .non_enum_variant()
} else { .fields
def.non_enum_variant().fields.iter().find(|item| item.ident.name == item_name) .iter()
}?; .find(|item| item.ident.name == item_name)?;
let kind = if def.is_enum() { DefKind::Variant } else { DefKind::Field }; Some((
let fragment = if def.is_enum() { root_res,
// FIXME: how can the field be a variant? UrlFragment::StructField(field.ident.name),
UrlFragment::Variant(field.ident.name) Some((DefKind::Field, field.did)),
} else { ))
UrlFragment::StructField(field.ident.name)
};
Some((root_res, fragment, Some((kind, field.did))))
} }
Res::Def(DefKind::Trait, did) => tcx Res::Def(DefKind::Trait, did) => tcx
.associated_items(did) .associated_items(did)