Skip to content

Unknown type from Lazy.lock() #2880

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
Timmmm opened this issue Jan 20, 2020 · 4 comments
Closed

Unknown type from Lazy.lock() #2880

Timmmm opened this issue Jan 20, 2020 · 4 comments
Labels
A-ty type system / type inference / traits / method resolution E-medium

Comments

@Timmmm
Copy link
Contributor

Timmmm commented Jan 20, 2020

I'm using once_cell's Lazy type, like this:

use once_cell::sync::Lazy;

struct State {
}

static STATE: Lazy<Arc<Mutex<State>>> = Lazy::new(|| {
  Arc::new(Mutex::new(Default::default()))
});

fn foo() {
  let a = STATE.lock();

If I hover STATE then it does show the type as static STATE: Lazy<Arc<Mutex<State>>>, however completion does not work (it doesn't offer .lock()), and if you hover a or lock it says {unknown}. I guess this is something to do with the Deref trait.

PS: This is with master from today (de24097).

@flodiebold
Copy link
Member

The Deref implementation is

impl<T, F: FnOnce() -> T> Deref for Lazy<T, F>

and Lazy is

pub struct Lazy<T, F = fn() -> T>

so the problem here is that we don't provide the built-in implementation of FnOnce for function pointers yet.

@flodiebold flodiebold added the A-ty type system / type inference / traits / method resolution label Jan 24, 2020
@Timmmm
Copy link
Contributor Author

Timmmm commented Jan 28, 2020

Is this hard to implement? I might have a go if you can point me in the right direction.

@flodiebold
Copy link
Member

flodiebold commented Feb 1, 2020

It's not trivial, but it's very similar to the existing built-in implementation of the Fn traits for closures, so it should be doable 🙂

Edit: removed outdated instructions. The current situation is that these impls should be added on the Chalk side; see rust-lang/chalk#363.

@flodiebold flodiebold added E-medium E-has-instructions Issue has some instructions and pointers to code to get started labels Feb 1, 2020
@montekki montekki mentioned this issue May 16, 2020
@flodiebold flodiebold removed the E-has-instructions Issue has some instructions and pointers to code to get started label May 17, 2020
bors bot added a commit that referenced this issue May 18, 2020
4493: Provide builtin impls of Fn traits for fn-pointers r=flodiebold a=hban

Meant to be, but isn't actually a fix for #2880.

Consider this snippet:

```rust
use std::marker::PhantomData;
use std::ops::Deref;

struct Lazy<T, F/* = fn() -> T*/>(F, PhantomData<T>);

impl<T, F> Lazy<T, F> {
    pub fn new(f: F) -> Lazy<T, F> {
        Lazy(f, PhantomData)
    }
}

impl<T, F: FnOnce() -> T> Deref for Lazy<T, F> {
    type Target = T;

    fn deref(&self) -> &T { todo!() }
}

fn test() {
    let lazy1: Lazy<u32, _> = Lazy::new(|| 0u32);
    let r1 = lazy1.to_string();

    fn make_u32_fn() -> u32 { todo!() }
    let make_u32_fn_ptr: fn() -> u32 = make_u32_fn;
    let lazy2: Lazy<u32, _> = Lazy::new(make_u32_fn_ptr);
    let r2 = lazy2.to_string();
}
```

* On current master:
  * When type default is commented-out, `r1` is correctly inferred, `r2` in _{unknown}_.
  * When type default is not commented-out, both `r1`  and `r2` are _{unknown}_.
* With this PR:
  * When type default is commented-out, both `r1` and `r2` are correctly inferred.
  * When type default is not commented-out, both `r1`  and `r2` are _{unknown}_.

Well, it's a improvement at least. I guess this thing with type defaults is a different problem.

I also tried add Fn impls for fn items, but wasn't successful. So this PR only adds those impls for fn pointers.

Co-authored-by: Hrvoje Ban <[email protected]>
@cynecx cynecx mentioned this issue Jun 25, 2020
@lnicola
Copy link
Member

lnicola commented Jun 29, 2020

Fixed by #5124.

@lnicola lnicola closed this as completed Jun 29, 2020
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 E-medium
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants