TAIT applies type constraints backwards where variable type is already fully constrained

This code works:

use core::ptr;
fn foo() -> impl Fn() {
    {
        fn bar(_: *const impl Sized) {}
        let p = ptr::null();
        if false {
            // This constrains the type of the pointer p
            return unsafe { ptr::read(p) };
        }
        bar(p);
    }
    || {}
}

However, the equivalent code using TAIT doesn't work.(edit: Yes, I see, this is not equivalent and the issue seems to be more about the incorrect error message and not that it doesn't work) Calling foo with argument p should constrain the impl Trait, but the constraints are applied backwards instead:

#![feature(type_alias_impl_trait)]
use core::ptr;
fn foo() -> impl Fn() {
    {
        type ReturnType = impl Sized;
        fn bar(_: *const ReturnType) {}
        let p = ptr::null();
        if false {
            // This constrains the type of the pointer p
            return unsafe { ptr::read(p) };
        }
        bar(p);
    }
    || {}
}

error[E0277]: expected a `Fn()` closure, found `ReturnType`
 --> src/main.rs:3:13
  |
3 | fn foo() -> impl Fn() {
  |             ^^^^^^^^^ expected an `Fn()` closure, found `ReturnType`
  |
  = help: the trait `Fn<()>` is not implemented for `ReturnType`
  = note: wrap the `ReturnType` in a closure with no arguments: `|| { /* code */ }`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `fooobar` (bin "fooobar") due to 1 previous error

rustc --version --verbose:

rustc 1.77.0-nightly (e51e98dde 2023-12-31)
binary: rustc
commit-hash: e51e98dde6a60637b6a71b8105245b629ac3fe77
commit-date: 2023-12-31
host: x86_64-unknown-linux-gnu
release: 1.77.0-nightly
LLVM version: 17.0.6

Start by running the reduced reproducer in src/main.rs with the reported nightly rustc version and compare the TAIT diagnostic with the non-TAIT example. Trace the compiler's TAIT and type-constraint handling to determine why the constraint direction produces the E0277 message; done means the constraint is handled correctly or the diagnostic accurately identifies the issue.