False positive warning from dereference-assignment of const pointer to mutable data

[nic-hartley]

I have quite a lot of MMIO in an embedded project, defined and used like this:

const REGISTER: *mut u32 = 0xDEADBEEF as *mut u32;
unsafe fn func() {
    *REGISTER = 1;
}

(see a playground link)

When I cargo build, I'm getting a whole host of warnings of the type:

warning: attempting to modify a `const` item
 --> src/lib.rs:3:5
  |
3 |     *REGISTER = 1;
  |     ^^^^^^^^^^^^^
  |
  = note: `#[warn(const_item_mutation)]` on by default
  = note: each usage of a `const` item creates a new temporary - the original `const` item will not be modified
note: `const` item defined here
 --> src/lib.rs:1:1
  |
1 | const REGISTER: *mut u32 = 0xDEADBEEF as *mut u32;
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I expect no warnings, because I'm not assigning to a const, I'm assigning to a dereferenced *mut u32, aka a mutable u32.

I couldn't figure out a playground example that would show the value actually mutating, but by hitting hardware registers I can prove that the value does get mutated, and it makes sense that it would: The pointer is const, but it's pointing to a mutable u32. Dereferencing shouldn't care whether the pointer variable is const.

Meta

rustc --version --verbose:

rustc 1.46.0 (04488afe3 2020-08-24)
binary: rustc
commit-hash: 04488afe34512aa4c33566eb16d8c912a3ae04f9
commit-date: 2020-08-24
host: x86_64-unknown-linux-gnu
release: 1.46.0
LLVM version: 10.0

No backtrace for this bug; it's a warning.

[nic-hartley]

There's a... fine, I guess, workaround of #![allow(const_item_mutation)] in my case, since all the MMIO code is bundled into a module away from the rest.

[jyn514]

cc @Aaron1011

[Aaron1011]

@nic-hartley This will be fixed by #77324

[nic-hartley]

@Aaron1011 Awesome, thanks so much!