Skip to content

"could be const_fn" False "positive" i.e., makes a recommendation that does not compile #4112

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
EdmundsEcho opened this issue May 19, 2019 · 3 comments

Comments

@EdmundsEcho
Copy link

EdmundsEcho commented May 19, 2019

This is a great tool to help accelerate my learning of the language.

Clippy seems to suggest that take_inner could be a const fn. However, when that change is made, the code does not compile: "destructors cannot be evaluated at compile-time".

I'm using the "late bounds" pattern for declaring a type parameter only in the "smart" constructor.

pub struct Wrapper<I> {
    inner: I,
}
impl<I> Wrapper<I> 
where
    I: Debug
{
    pub fn new(a: I) -> Self
    // fn:: I -> Wrapper I
    {
        Wrapper { inner: a }
    }
    pub fn inspect(&self)
    // fn:: Wrapper I -> ()
    {
        println!("{:?}", self.inner);
    }
}
pub fn take_inner<I>(w: Wrapper<I>) -> I {  // <<< lint suggestion here fails to compile
    w.inner
}
@EdmundsEcho EdmundsEcho changed the title The clippy lint db does not include a separate entry for "unused type parameter" "could be const_fn" False "positive" i.e., makes a recommendation that might not be true - May 19, 2019
@EdmundsEcho EdmundsEcho reopened this May 19, 2019
@EdmundsEcho EdmundsEcho changed the title "could be const_fn" False "positive" i.e., makes a recommendation that might not be true - "could be const_fn" False "positive" i.e., makes a recommendation that does not compile May 19, 2019
@oli-obk
Copy link
Contributor

oli-obk commented May 19, 2019

I opened rust-lang/rust#60964 on the rustc repo, because that should be allowed as const fn.

@phansch
Copy link
Member

phansch commented May 19, 2019

@oli-obk Is this the same underlying cause as #4041?

@oli-obk
Copy link
Contributor

oli-obk commented May 19, 2019

yes. I just immediately assumed one needs generics for this

@oli-obk oli-obk closed this as completed May 19, 2019
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

3 participants