Rustc beta/nightly appears to ignore unsafe blocks inside closure in some cases

[inrustwetrust]

The code below compiles with stable rustc (1.52.1), but fails to compile on beta (1.53) and nightly (1.54):

fn main() {
    let val: u8 = 5;
    let u8_ptr: *const u8 = &val;
    let _closure = || {
        unsafe {
            // Fails compilation with:
            // error[E0133]: dereference of raw pointer is unsafe and
            //               requires unsafe function or block
            let tmp = *u8_ptr;
            tmp

            // Just dereferencing and returning directly compiles fine:
            // *u8_ptr
        }
    };
}

On beta and nightly, there is a compilation error due to a missing unsafe block, even though there clearly is one in the code:

error[E0133]: dereference of raw pointer is unsafe and requires unsafe function or block
 --> unsafe_deref_test.rs:9:23
  |
9 |             let tmp = *u8_ptr;
  |                       ^^^^^^^ dereference of raw pointer
  |
  = note: raw pointers may be NULL, dangling or unaligned; they can violate aliasing rules and cause data races: all of these are undefined behavior

error: aborting due to previous error

For more information about this error, try `rustc --explain E0133`.

Meta

Compilation error:
rustup run beta rustc --version --verbose:

rustc 1.53.0-beta.2 (4bac69dd2 2021-05-07)
binary: rustc
commit-hash: 4bac69dd25089dd2f803f24de2225d84449b6220
commit-date: 2021-05-07
host: x86_64-apple-darwin
release: 1.53.0-beta.2
LLVM version: 12.0.0

Compilation error:
rustup run nightly rustc --version --verbose:

rustc 1.54.0-nightly (fe72845f7 2021-05-16)
binary: rustc
commit-hash: fe72845f7bb6a77b9e671e6a4f32fe714962cec4
commit-date: 2021-05-16
host: x86_64-apple-darwin
release: 1.54.0-nightly
LLVM version: 12.0.1

Successful compilation:
rustup run stable rustc --version --verbose:

rustc 1.52.1 (9bc8c42bb 2021-05-09)
binary: rustc
commit-hash: 9bc8c42bb2f19e745a63f3445f1ac248fb015e53
commit-date: 2021-05-09
host: x86_64-apple-darwin
release: 1.52.1
LLVM version: 12.0.0

[hameerabbasi]

Assigning a priority as discussed in WG-prioritization discussion on Zulip and removing I-prioritize.

@rustbot modify labels -I-prioritize +P-high

[ehuss]

Bisected to #83855, I strongly suspect it is #83521. cc @roxelo

[pnkfelix]

discussed in compiler triage. Heightening priority and self-assigning.

[pnkfelix]

some discussion in zulip.

I have confirmed this was injected by PR #83521. I have filed issue #85561 for the root cause, and put up PR #85564 as a targeted fix suitable for a beta-backport.

[pietroalbini]

Fixed in 1.54 by #85564 and fixed in 1.53 by #85893. Closing.