Skip to content

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