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

Double same-bound where clause causes failed type inference #132667

Open
collinoc opened this issue Nov 5, 2024 · 2 comments
Open

Double same-bound where clause causes failed type inference #132667

collinoc opened this issue Nov 5, 2024 · 2 comments
Labels
A-trait-system Area: Trait system C-bug Category: This is a bug. E-needs-investigation Call for partcipation: This issues needs some investigation to determine current status T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-types Relevant to the types team, which will review and decide on the PR/issue.

Comments

@collinoc
Copy link
Contributor

collinoc commented Nov 5, 2024

I came across this scenario where having two functions with the same where-bounds causes type inference failure:

pub fn foo<S>(_: S) where String: From<S> {}
pub fn bar<S>(s: S) where String: From<S> {
    // Mismatched types error!
    foo(String::from(s)); 
}

I would expect the type inference to hold up and allow for calling foo with a String constructed in bar. Instead it fails with a mismatched types error (E0308) saying expected type parameter `S`, found `String`

Notably, ANY String or &str constructed in bar and passed to foo will fail type inference. For example:

pub fn baz<S>(_: S) where String: From<S> {
    // Mismatched types error!
    foo(""); 
}

pub fn bam<S>(_: S) where String: From<S> {
    // Mismatched types error!
    let s: String = "".to_owned();
    foo(s); 
}

Some examples of similar scenarios that work, but show that there shouldn't be anything wrong with the actual operation (particularly bap):

pub fn bam<S>(s: S) where String: From<S> {
    // OK!
    foo(s); 
}
pub fn bap<S>(s: S) where String: From<S> {
    // OK!
    foo::<String>(String::from(s)); 
}
pub fn bao() {
    // OK!
    let s: String = "".to_owned();
    foo(s); 
}

// Strangely, inverting the From bound to an Into bound fixes things
pub fn foo2<S>(_: S) where S: Into<String> {}
pub fn bar2<S>(s: S) where String: From<S> {
    // OK!
    foo2(String::from(s)); 
}

Meta

This occurs on stable (1.82.0), beta (1.83.0-beta.4 // 2024-11-02 67512de), and nightly (1.83.0-nightly // 2024-11-03 b8c8287) in debug and release modes.

Full Playground Link

@collinoc collinoc added the C-bug Category: This is a bug. label Nov 5, 2024
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Nov 5, 2024
@hanna-kruppe
Copy link
Contributor

I think this is #24066 yet again.

@lolbinarycat lolbinarycat added A-trait-system Area: Trait system T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 6, 2024
@jieyouxu jieyouxu added the T-types Relevant to the types team, which will review and decide on the PR/issue. label Nov 11, 2024
@jieyouxu
Copy link
Member

Labelling as needs-investigation for someone more knowledgeable to double-check if it's the same root cause.
@rustbot label +E-needs-investigation -needs-triage

@rustbot rustbot added E-needs-investigation Call for partcipation: This issues needs some investigation to determine current status and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Nov 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-trait-system Area: Trait system C-bug Category: This is a bug. E-needs-investigation Call for partcipation: This issues needs some investigation to determine current status T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-types Relevant to the types team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants