Skip to content

Type inference failure when passing a closure in place of a function parameter #15148

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
ghost opened this issue Jun 24, 2014 · 1 comment
Closed

Comments

@ghost
Copy link

ghost commented Jun 24, 2014

pub struct Foo<A,B> {
    f: fn(A, B) -> bool
}

impl<A,B> Foo<A,B> {
    pub fn new(f: fn(A, B) -> bool) -> Foo<A,B> {
        Foo { f: f }
    }
}

fn main() {
    let foo = Foo::<bool,bool>::new(|a,b| -> bool { a && b });
}

main.rs:15:57: 15:58 error: the type of this value must be known in this context
main.rs:15 let foo = Foo::<bool,bool>::new(|a,b| -> bool { a && b });

It does work when changing the code to expect a closure rather than a function, or when passing the expected function, but the error message here is either wrong/misleading, or there's a real bug.

@steveklabnik
Copy link
Member

Closures have since been re-done, so this bug is now invalid.

bors added a commit to rust-lang-ci/rust that referenced this issue Jul 17, 2023
…ykril

Fix `self` and `super` path resolution in block modules

This PR fixes `self` and `super` path resolution with block modules involved.

Previously, we were just going up the module tree count-of-`super` times without considering block modules in the way, and then if we ended up in a block `DefMap`, we adjust "to the containing crate-rooted module". While this seems to work in most real-world cases, we failed to resolve them within peculiar module structures.

`self` and `super` should actually be resolved to the nearest non-block module, and the paths don't necessarily resolve to a crate-rooted module. This PR makes sure every `self` and `super` segment in paths are resolved to a non-block module.
lnicola pushed a commit to lnicola/rust that referenced this issue Oct 29, 2024
I.e. the following situation:
```
fn foo() {
    mod bar {
        fn qux() {
            // Prelude path here (e.g. macro use prelude or extern prelude).
        }
    }
}
```
Those were previously unresolved, because, in order to support `self` and `super` properly, since rust-lang#15148 we do not ascend block paths when there is a module in between, but only crate def maps register preludes, not block def maps, and we can't change this because block def map prelude can always be overridden by another block. E.g.
```
fn foo() {
    struct WithTheSameNameAsPreludeItem;
    {
        WithTheSameNameAsPreludeItem
    }
}
```
Here `WithTheSameNameAsPreludeItem` refer to the item from the top block, but if we would register prelude items in each block the child block would overwrite it incorrectly.
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

1 participant