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

StableMIR: Add associated_items. #138826

Draft
wants to merge 4 commits into
base: master
Choose a base branch
from
Draft

Conversation

makai410
Copy link
Contributor

No description provided.

- Add `AssocItem` and related things to `stable_mir::ty`.
- Implement `Display` for `AssocKind`.
@rustbot
Copy link
Collaborator

rustbot commented Mar 22, 2025

r? @celinval

rustbot has assigned @celinval.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 22, 2025
@makai410
Copy link
Contributor Author

Lack of the ui-test for it. I open this pr for some feedback first.

@makai410
Copy link
Contributor Author

makai410 commented Mar 22, 2025

My question is what data structure should be used for AssocItems (Currently Vec<(Symbol, AssocItem)>)? btw, I think there may be some problem with OpaqueDef, unsure if my version is correct.

@makai410
Copy link
Contributor Author

Forgot to mention that there may be some issues with the retrieved associated items that the compiler generated after RPITIT desugaring.

For example:

        trait Ciallo {
            fn rpitit(&self) -> impl std::fmt::Debug {
                "RPITIT"
            }
        }

get all associated items of this trait by associated_items():

AssocItems {
    items: [
        (
            "rpitit",
            AssocItem {
                def_id: AssocDef(
                    DefId {
                        id: 17336,
                        name: "Ciallo::rpitit",
                    },
                ),
                name: "rpitit",
                kind: Fn,
                container: Trait,
                trait_item_def_id: Some(
                    AssocDef(
                        DefId {
                            id: 17336,
                            name: "Ciallo::rpitit",
                        },
                    ),
                ),
                fn_has_self_parameter: true,
                opt_rpitit_info: None,
            },
        ),
        (
            "",
            AssocItem {
                def_id: AssocDef(
                    DefId {
                        id: 17338,
                        name: "Ciallo::{synthetic#0}",
                    },
                ),
                name: "",
                kind: Type,
                container: Trait,
                trait_item_def_id: None,
                fn_has_self_parameter: false,
                opt_rpitit_info: Some(
                    Trait {
                        fn_def_id: FnDef(
                            DefId {
                                id: 17336,
                                name: "Ciallo::rpitit",
                            },
                        ),
                        opaque_def_id: OpaqueDef(
                            DefId {
                                id: 17339,
                                name: "Ciallo::rpitit::{opaque#0}",
                            },
                        ),
                    },
                ),
            },
        ),
    ],
}

The problem is the name of the generated associated type is "". I have no knowledge of RPITIT desugaring, unsure if this is an issue and whether we should slap a name to it.

@celinval
Copy link
Contributor

My question is what data structure should be used for AssocItems (Currently Vec<(Symbol, AssocItem)>)?

Can you do Vec<AssocItem> instead? From what I understood, the Symbol is redundant since it duplicates name from AssocItem.

@makai410
Copy link
Contributor Author

Oh yes, it makes sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants