Skip to content

Operator overloading type inference Error #7150

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

Closed
MATRIXKOO opened this issue Jan 4, 2021 · 5 comments · Fixed by #8457
Closed

Operator overloading type inference Error #7150

MATRIXKOO opened this issue Jan 4, 2021 · 5 comments · Fixed by #8457
Labels
A-ty type system / type inference / traits / method resolution S-actionable Someone could pick this issue up and work on it right now

Comments

@MATRIXKOO
Copy link

use std::ops::Add;

struct wrapper_f64{test: f64}
impl Add<usize> for wrapper_f64{
    type Output = Self;
    fn add(self , rhs : usize)-> wrapper_f64{
        wrapper_f64{test: self.test + rhs as f64}
    }
}
fn main(){
    let f64_in = wrapper_f64{test: 1.0};
    let usize_num : usize = 2;
    let res = f64_in + usize_num;

}

when I run those codes on
rustc: stable-x86_64-unknown-linux-gnu - rustc 1.49.0
OS: window wsl
RA is update-to-date
RA type inference like
img
And the real type of res should be wrapper_f64

@lnicola lnicola added A-ty type system / type inference / traits / method resolution S-actionable Someone could pick this issue up and work on it right now labels Jan 4, 2021
@ruabmbua
Copy link
Contributor

The code, which does type inference in expressions has a explicit path for primitive types (probably for speedup), which handles this kind of inference wrong.

If you remove the explicit handling of primitive types, this specific example resolves the type correctly.

Even if we get rid of the explicit built-in type handling, there are cases where types are resolved incorrectly for operator overloads: #5685.

This is (I think) an issue with chalk.

@flodiebold
Copy link
Member

I'd still like to keep the built-in handling, and rather fix it so it doesn't apply in those wrong cases.

@PaulRBerg
Copy link

PaulRBerg commented Jan 15, 2021

I am encountering a similar issue caused by an overloaded call method:

multicall.call().await?;

rust-analyzer finds this error even if the code compiles fine:

Capture d’écran 2021-01-15 à 10 41 28

The defintion of the call method on the Multisol struct:

pub async fn call<D: Detokenize>(&self) -> Result<D, ContractError<M>> {
    ...
}

The catch is that the Multicall struct also implements the Middleware trait, which defines call as:

async fn call(
    &self,
    tx: &TransactionRequest,
    block: Option<BlockNumber>,
) -> Result<Bytes, Self::Error> {
    ...
}

These types are from ethers-rs.

@flodiebold
Copy link
Member

That's not the same issue. Can you make a separate report please?

@PaulRBerg
Copy link

Oh, sorry @flodiebold. Will do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ty type system / type inference / traits / method resolution S-actionable Someone could pick this issue up and work on it right now
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants