-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[rustdoc-json] Free-floating struct_field
items with enum tuple struct variants
#92945
Comments
Proof-of-concept fix to experiment with can be found at Enselic#1. I have done some casual verification of that change and it appears to solve the problem in a good way. But the fix requires more thought and testing. |
struct_field
item with enum tuple structstruct_field
items with enum tuple struct variants
…-fields, r=CraftSpider src/test/rustdoc-json: Check for `struct_field`s in `variant_tuple_struct.rs` The presence of `struct_field`s is being checked for already in `variant_struct.rs`. We should also check for them in `variant_tuple_struct.rs`. This PR is one small step towards resolving rust-lang#92945.
This happens because we add all the inner items here rust/src/librustdoc/clean/types.rs Line 774 in 6c943ba
but I think it's better to move to having fields as their own item |
…GuillaumeGomez Rustdoc-Json: Store Variant Fields as their own item. Closes rust-lang#100587 Closes rust-lang#92945 Successor to rust-lang#100762 Unlike that one, we don't have merge `StructType` and `Variant`, as after rust-lang#101386 `Variant` stores enum specific information (discriminant). Resolves the naming discussion (rust-lang#100762 (comment)) by having seperate enums for struct and enum kinds Resolves `#[doc(hidden)]` on tuple structs (rust-lang#100762 (comment)) by storing as a `Vec<Option<Id>>` r? `@GuillaumeGomez`
There is currently a problematic inconsistency with regards to the generated rustdoc JSON for tuple structs. If the tuple struct is an enum variant, a "parentless" or "free-floating" item is generated. This does not happen with regular tuple structs.
Consider this code in
src/lib.rs
.Now we generate the rustdoc JSON (I used
rustc 1.60.0-nightly (ad46af247 2022-01-14)
):The rustdoc JSON output will contain 4
struct_field
items, corresponding toS1.0
,S2.0
,S3.s3
andS4.s4
above.The JSON item for
S1
includes a reference toS1.0
(some parts of the JSON are omitted for brevity):And the JSON item for
S3
includes a reference toS3.s3
:And the JSON item for
S4
includes a reference toS4.s4
:However, and this is the bug, the JSON item for
S2
does not contain a reference toS2.0
:But an item for
S2.0
is still included in the output. Here are allstruct_field
items in the JSON output:but
"0:9"
is "free-floating" or "parentless", because it is not referenced by any other item. These "free-floating" rustdoc JSON items that are not referenced by any other items are problematic, because tools that processes the rustdoc JSON can't do anything sensible with them. They can't be ignored, because they describe items that are part of the public API of a crate. But they can't be used either, because they can not be put in a context since they are not referenced by anything.Fortunately, I think fixing this is pretty straightforward. First, let us note that for a regular struct, the fields of it are referenced regardless of if it is a regular struct or a tuple struct (code from https://github.com/rust-lang/rust/blob/master/src/rustdoc-json-types/lib.rs):
However, for enum variant structs, fields are only referenced for regular struct variants:
Conceptually I think the fix should be to replace
Tuple(Vec<Type>),
withTuple(Vec<Id>),
in the snippet above. But I have not thought this through in depth, it just intuitively seems like the right way to tackle this.The text was updated successfully, but these errors were encountered: