Skip to content

Do not expect infer/bound/placeholder/error in v0 symbol mangling #130485

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

Merged
merged 1 commit into from
Sep 20, 2024

Conversation

compiler-errors
Copy link
Member

@compiler-errors compiler-errors commented Sep 17, 2024

Infer/bound/placeholder/error are not encounterable during codegen. Let's make sure v0 symbol mangling doesn't "accidentally" handle them.

As for aliases (namely: projections and uv consts) these may still be encounterable because of the way that we render the def paths of items. Specifically, when we have something like:

struct W<T>(T);

impl<T> W<T> {
    fn x() {
        fn y() {}
    }
}

The path of y is rendered like crate_name::W<T>::x::y. Specifically, since y doesn't inherit the generics of the impl, we use the identity substitutions for that impl. If the impl has any aliases, they will remain unnormalized if they're rigid.

r? @BoxyUwU

@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 Sep 17, 2024
// Never cached (single-character).
self.push("p");
return Ok(());
}

ty::Unevaluated(..) => bug!("symbol_names: unexpected unnormalized alias"),
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should be normalized


ty::Unevaluated(..) => bug!("symbol_names: unexpected unnormalized alias"),

ty::ConstKind::Expr(_)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should either be normalized (expr), unconstructable (infer/placeholder), unreachable (bound) or already dealt with (error).

@rust-log-analyzer

This comment has been minimized.

@compiler-errors
Copy link
Member Author

omg in the wild

@compiler-errors compiler-errors changed the title Do not expect aliases/infer/bound/placeholder/error in v0 symbol mangling Do not expect infer/bound/placeholder/error in v0 symbol mangling Sep 17, 2024
@compiler-errors
Copy link
Member Author

OK, I clarified when aliases are encountered in v0 symbol mangling. What a mess tbh lol

@BoxyUwU
Copy link
Member

BoxyUwU commented Sep 19, 2024

@bors r+ rollup

@bors
Copy link
Collaborator

bors commented Sep 19, 2024

📌 Commit 87bc2f7 has been approved by BoxyUwU

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 19, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 20, 2024
…iaskrgr

Rollup of 3 pull requests

Successful merges:

 - rust-lang#130485 (Do not expect infer/bound/placeholder/error in v0 symbol mangling)
 - rust-lang#130567 (Register tool docs for compiletest)
 - rust-lang#130582 (rustdoc: use the correct span for doctests)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit b963750 into rust-lang:master Sep 20, 2024
6 checks passed
@rustbot rustbot added this to the 1.83.0 milestone Sep 20, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Sep 20, 2024
Rollup merge of rust-lang#130485 - compiler-errors:impossible-types, r=BoxyUwU

Do not expect infer/bound/placeholder/error in v0 symbol mangling

Infer/bound/placeholder/error are not encounterable during codegen. Let's make sure v0 symbol mangling doesn't "accidentally" handle them.

As for aliases (namely: projections and uv consts) these may still be encounterable because of the way that we render the def paths of items. Specifically, when we have something like:

```
struct W<T>(T);

impl<T> W<T> {
    fn x() {
        fn y() {}
    }
}
```

The path of `y` is rendered like `crate_name::W<T>::x::y`. Specifically, since `y` doesn't inherit the generics of the impl, we use the *identity* substitutions for that impl. If the impl has any aliases, they will remain unnormalized if they're rigid.

r? `@BoxyUwU`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. 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.

5 participants