Skip to content
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

Rename json::ItemEnum to ItemKind #80142

Closed
jyn514 opened this issue Dec 18, 2020 · 6 comments
Closed

Rename json::ItemEnum to ItemKind #80142

jyn514 opened this issue Dec 18, 2020 · 6 comments
Assignees
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@jyn514
Copy link
Member

jyn514 commented Dec 18, 2020

This was renamed in clean in #79041, but I missed json.

Originally posted by @jyn514 in #80119 (comment)

@jyn514 jyn514 added C-cleanup Category: PRs that clean code up or issues documenting cleanup. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Dec 18, 2020
@pierwill
Copy link
Member

@rustbot claim

@pierwill
Copy link
Member

Doing a simple LSP renaming command, got this error:

error[E0428]: the name `ItemKind` is defined multiple times
   --> src/librustdoc/json/types.rs:188:1
    |
158 | pub enum ItemKind {
    | ----------------- previous definition of the type `ItemKind` here
...
188 | pub enum ItemKind {
    | ^^^^^^^^^^^^^^^^^ `ItemKind` redefined here
    |
    = note: `ItemKind` must be defined only once in the type namespace of this module

There is already a json::ItemKind type. Shall we use another name?

@jyn514
Copy link
Member Author

jyn514 commented Dec 20, 2020

It's not clear to me why Item has both a kind and inner field. @P1n3appl3 do you remember the reason for that?

@P1n3appl3
Copy link
Contributor

In the output we had items be "adjacently tagged" where they store the kind in a separate field instead of having the inner field be like an object with 1 key (the kind) and the inner ItemEnum as the value. Serde has an option to do that adjacent tagging automatically but it didn't work for ItemEnum for some reason iirc so instead we explicitly provide the kind alongside inner.

It's not strictly necessary if you're using serde on both ends (it figures out which kind of ItemEnum it is based its contents when deserializing) but we wanted it to be easy to use other tools/languages to process the json where it'd be simpler to switch on a single field's value.

Also looking at it now I remember that there's a couple of kinds of items (union, foreign function, and TyMethod) which reuse the ItemEnum representations from other kinds because they're identical but have separate ItemKinds to distinguish which one they were. It's doesn't have to be that way (you could just duplicate the types and give them different names like I think Clean does) buy it's something to watch out for if you're changing it.

Oh and also ItemSummary needs the kind of the item but not the contents of it's ItemEnum so it may be best to keep ItemKind around actually now that I think about it.

@jyn514
Copy link
Member Author

jyn514 commented Dec 20, 2020

Hmm, ok. That makes sense, this sounds tricky to fix without changing the stable format. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants