Skip to content
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

Discrepancy in closure modes #3643

Closed
kyledj opened this issue Oct 3, 2012 · 6 comments
Closed

Discrepancy in closure modes #3643

kyledj opened this issue Oct 3, 2012 · 6 comments

Comments

@kyledj
Copy link

kyledj commented Oct 3, 2012

The following code compiles and works as expected:

let a = &"something".all(|c: char| -> bool { c == 'a' });

This code, however:

let char_is_a = fn&(c: char) -> bool { c == 'a' };
let b = &"something".all(char_is_a);

gives the following error:

str_tut.rs:28:26: 28:35 error: mismatched types: expected `fn&(++:char) -> bool` but found `fn&(char) -> bool` (expected argument mode ++, but found +)
str_tut.rs:28   let b = &"something".all(char_is_a);
                                        ^~~~~~~~~
error: aborting due to previous error

If I add the mode to the char_is_a definition, it works. It just seems odd to have this discrepancy.

@nikomatsakis
Copy link
Contributor

What version of rustc are you using? I would not expect this to be true on the most recent incoming, but earlier versions and master may still exhibit this behavior.

@nikomatsakis
Copy link
Contributor

In particular this commit 9284179 most likely fixes this issue.

@kyledj
Copy link
Author

kyledj commented Oct 3, 2012

I originally had this issue on master. I compiled incoming (73b2a93), and had the same issue, so not sure if it is resolved.

@nikomatsakis
Copy link
Contributor

So more specifically, with the latest incoming, this test works for me:

fn main() {
    fn foo(c: char) -> bool { c == 'a' }
    let a = &"something".all(foo);
}

@nikomatsakis
Copy link
Contributor

As did this:

fn main() {
    let foo = fn&(c: char) -> bool { c == 'a' };
    let a = &"something".all(foo);
}

@kyledj
Copy link
Author

kyledj commented Oct 3, 2012

Ugh. I'm not sure what was up with my environment when I was running rustc this morning, but recompiling incoming seemed to have fixed it. The latest does fix these issues.

@kyledj kyledj closed this as completed Oct 3, 2012
flip1995 pushed a commit to flip1995/rust that referenced this issue Sep 8, 2021
Use binary-dep-depinfo to resolve UI test dependencies

Closes rust-lang#7343
Closes rust-lang#6809
Closes rust-lang#3643

changelog: none

r? `@flip1995`
cc `@Jarcho`
RalfJung pushed a commit to RalfJung/rust that referenced this issue Jun 9, 2024
`PackageId` is an opaque identifier whose internal format is subject to
change, so looking up the names of local crates by ID is more robust
than parsing the ID.

Resolves rust-lang#3643.
RalfJung pushed a commit to RalfJung/rust that referenced this issue Jun 9, 2024
…pdate, r=RalfJung

Fix "local crate" detection

`PackageId` is an opaque identifier whose internal format is subject to change, so looking up the names of local crates by ID is more robust than parsing the ID.

Resolves rust-lang#3643.
lcnr pushed a commit to lcnr/rust that referenced this issue Jun 12, 2024
`PackageId` is an opaque identifier whose internal format is subject to
change, so looking up the names of local crates by ID is more robust
than parsing the ID.

Resolves rust-lang#3643.
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

2 participants