Call implementations of the Fn* traits on references

[mikem8891]

This pull request fixes Issue #42736, allowing references of structs, enums, and unions to implement Fn* traits and be called. For example, the code below will compile and run properly. If approved this should also push Issue #29625 forward as well.

#![feature(fn_traits)]
#![feature(unboxed_closures)]

struct S;

impl FnOnce<()> for &S {
    type Output = ();

    extern "rust-call" fn call_once(self, _arg: ()) {
        println!("Haldo, world!");
    }
}

fn main() {
    let s = S;
    (&s)();
}

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Noratrieb (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[workingjubilee]

huh, meaning-changing formatting...?

[theemathas]

@workingjubilee It's not a "meaning-changing formatting" issue. For some reason, the diff in rust-lig-analyzer's comment does not match the diff in the actual logs.

[workingjubilee]

oh weird.

[compiler-errors]

The diff in rust-log-analyzer just renders weirdly for some reason.

However, this still needs a test associated with it, and a pretty clear explanation of the root cause of the issue and why this fixes it. Also, yeah, please fix the formatting.

I also don't think we should land this regardless, personally; Fn* traits are pretty internal still, and there's specific HIR typeck hacks that need to be adjusted in general.

@rustbot author

[rust-log-analyzer]

The job x86_64-gnu-llvm-18 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

#21 exporting to docker image format
#21 sending tarball 27.2s done
#21 DONE 40.8s
##[endgroup]
Setting extra environment values for docker:  --env ENABLE_GCC_CODEGEN=1 --env GCC_EXEC_PREFIX=/usr/lib/gcc/
[CI_JOB_NAME=x86_64-gnu-llvm-18]
debug: `DISABLE_CI_RUSTC_IF_INCOMPATIBLE` configured.
---
sccache: Starting the server...
##[group]Configure the build
configure: processing command line
configure: 
configure: build.configure-args := ['--build=x86_64-unknown-linux-gnu', '--llvm-root=/usr/lib/llvm-18', '--enable-llvm-link-shared', '--set', 'rust.randomize-layout=true', '--set', 'rust.thin-lto-import-instr-limit=10', '--enable-verbose-configure', '--enable-sccache', '--disable-manage-submodules', '--enable-locked-deps', '--enable-cargo-native-static', '--set', 'rust.codegen-units-std=1', '--set', 'dist.compression-profile=balanced', '--dist-compression-formats=xz', '--set', 'rust.lld=false', '--disable-dist-src', '--release-channel=nightly', '--enable-debug-assertions', '--enable-overflow-checks', '--enable-llvm-assertions', '--set', 'rust.verify-llvm-ir', '--set', 'rust.codegen-backends=llvm,cranelift,gcc', '--set', 'llvm.static-libstdcpp', '--enable-new-symbol-mangling']
configure: target.x86_64-unknown-linux-gnu.llvm-config := /usr/lib/llvm-18/bin/llvm-config
configure: llvm.link-shared     := True
configure: rust.randomize-layout := True
configure: rust.thin-lto-import-instr-limit := 10

[mikem8891]

I fixed the formatting and added a short explanation of the change in the comments.

As for the original cause of the (Issue #42736)[https://github.com//issues/42736], it is caused during the probing phase of type checking. rustc_hir_typeck::callee::FnCtxt::try_overloaded_call_step contains a hack that causes all Ref Candidates to be automatically discarded so the autoderef can move on to the next step of dereferencing. This allows &fn() and similar closures to be dereferenced further. This allows references to closures and function pointers that implement and call using FnMut to not require a &mut. This should not apply to structs, enums, or unions; as they would actually mutate self.

The tests to add seem like they would be pretty straight forward. This is my first pull request, so I apologize if I have missed any steps. Where in the tests should I put my tests?

Unless I am actively working against someone who is already working to fix this and the other HIR typeck hacks, I don't see any harm in fixing this issue now.

Thank you!
@rustbot review

[compiler-errors]

Unless I am actively working against someone who is already working to fix this and the other HIR typeck hacks, I don't see any harm in fixing this issue now.

This adds complexity to HIR typeck for a compiler-only feature. I don't think we really should be fixing this, especially because I cannot see an FnOnce for &Adt being implemented in a practical way without a corresponding Fn impl.

Thanks for the contribution, but I'm gonna opt to close it.

[compiler-errors]

If approved this should also push #29625 forward as well.

The blocker for stabilizing the Fn traits is a lot more than just trivial implementation bugs; there's a lot of open questions and caveats about exposing the extern "rust-call" ABI and how to represent function arguments and variadics and other things like that.