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

non-defining uses with non-param args will be breaking #135

Open
lcnr opened this issue Dec 5, 2024 · 3 comments
Open

non-defining uses with non-param args will be breaking #135

lcnr opened this issue Dec 5, 2024 · 3 comments

Comments

@lcnr
Copy link
Contributor

lcnr commented Dec 5, 2024

https://rust.godbolt.org/z/Yoc1efvxc

trait Recur {
    fn recur(self);
}

impl<T> Recur for () {
    fn recur(self) {}
}

fn recurse_no_define<T>(b: bool) -> impl Recur {
    if b {
        recurse_no_define::<()>(false).recur();
    }
}

This currently compiles, but even just tryin got normalize the RPIT of the recursive call will fail as it does not have fully generic args.

Normalization fails and we don't treat the opaque as rigid

@lcnr
Copy link
Contributor Author

lcnr commented Dec 5, 2024

sus idea:

The reason we don't support defining opaques with unique params as args as that otherwise the mapping from the opaque to the hidden type is unclear: e.g. RPIT<u8> = u8 could either define RPIT<T> = T or RPIT<T> = u8.

This is only an issue if there is no proper defining use. If we had one defining use RPIT<T> = T and another one using RPIT<u8> = u8, we could use the fully general one to define the hidden type, and then only check that the hidden type of the non-general one by instantiating that hidden type with u8 in this case and equating them

@lcnr
Copy link
Contributor Author

lcnr commented Dec 5, 2024

The same approach would also allow non-defining uses of an opaque as long as there is one use which fully defines. E.g.

If we use define Opaque<T, U> = T and Opaque<U, T> = ?x this currently errors, but we could take the Opaque<T, U> = T definition, map the hidden type to the context of the opaque, and then instantiate it with U and T, constraining ?x . This does not seem very desirable, but may be necessary to avoid breaking changes because the new solver tries to normalize opaques currently treated as rigid

@compiler-errors
Copy link
Member

This also doesn't work as soon as the opaque has lifetimes since we need region info to correlate the regions of the defining use w the hidden type.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants