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

fn std::mem::drop() not accepted as argument of type fn(&Arg) #96057

Open
panstromek opened this issue Apr 14, 2022 · 4 comments
Open

fn std::mem::drop() not accepted as argument of type fn(&Arg) #96057

panstromek opened this issue Apr 14, 2022 · 4 comments
Labels
A-inference Area: Type inference C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@panstromek
Copy link
Contributor

panstromek commented Apr 14, 2022

I tried this code:

struct Arg(i8);

fn takes_cb(cb: fn(&Arg)) {}


fn takes_arg(a: &Arg) {}

fn main() {
    takes_cb(takes_arg); // this is ok
    takes_cb(|_|( )); // this is ok
    takes_cb(drop); // this is an error
}

I expected to see this happen:
I expect the code to compile. It looks like this should work, because drop should be more or less equivalent to toilet closure, it just has generic argument, but without any bounds, so it seems like it should be accepted here.

Instead, this happened:

Code doesn't compile with:

error[E0308]: mismatched types
   --> crates/legacy-zebra/src/game.rs:315:14
    |
315 |     takes_cb(drop);
    |              ^^^^ one type is more general than the other
    |
    = note: expected fn pointer `for<'r> fn(&'r Arg)`
               found fn pointer `fn(&Arg)`

Meta

rustc --version --verbose:

rustc 1.60.0-nightly (75d9a0ae2 2022-02-16)
binary: rustc
commit-hash: 75d9a0ae210dcd078b3985e3550b59064e6603bc
commit-date: 2022-02-16
host: x86_64-unknown-linux-gnu
release: 1.60.0-nightly
LLVM version: 13.0.0
@panstromek panstromek added the C-bug Category: This is a bug. label Apr 14, 2022
@csmoe

This comment was marked as off-topic.

@csmoe csmoe closed this as completed Apr 16, 2022
@csmoe csmoe marked this as a duplicate of #41078 Apr 16, 2022
@panstromek
Copy link
Contributor Author

@csmoe That doesn't seem like the same issue, because #41078 talks about inferred types of closures, but here the problem is with a free function, not a closure. The problem doesn't seem to be an inference, but coercion.

@csmoe

This comment was marked as off-topic.

@panstromek
Copy link
Contributor Author

panstromek commented Apr 16, 2022

The problem here is that drop is generic, so it can't even express such a bound because the reference is just <T> in drop's definition. Is that really the same issue as incorrect type inference of a closure? I still don't see the connection.

@csmoe csmoe reopened this Apr 17, 2022
@ChrisDenton ChrisDenton added the needs-triage-legacy Old issue that were never triaged. Remove this label once the issue has been sufficiently triaged. label Jul 16, 2023
@Enselic Enselic changed the title Cannot use drop in place where toilet closure works if the argument is a reference fn std::mem::drop() not accepted as argument of type fn(&Arg) Jul 30, 2024
@Enselic Enselic added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. A-inference Area: Type inference and removed needs-triage-legacy Old issue that were never triaged. Remove this label once the issue has been sufficiently triaged. labels Jul 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-inference Area: Type inference C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants