You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
…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.
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.
The text was updated successfully, but these errors were encountered: