&raw mut of a static mut treated as simultaneously safe and unsafe

[cbiffle]

On 1.82.0, rust-analyzer seems to have mixed opinions about place expressions in the newly stabilized &raw syntax. This bug also affects uses of the older addr_of/addr_of_mut macros. Specifically, it reports an error that was valid in 1.81 but is not correct in 1.82, and also warns (correctly) if you fix the "error" it describes.

rust-analyzer version: the one distributed with 1.82.0 through rustup (instructions were only given for finding the version through VScode, which I don't use): rust-analyzer 1.82.0 (f6e511e 2024-10-15)

rustc version: rustc 1.82.0 (f6e511eec 2024-10-15)

editor or extension: neovim + rustaceanvim

relevant settings: Not sure if it's relevant, but I am cross-compiling for thumbv7em-none-eabihf on an x86 linux host.

code snippet to reproduce:

static mut BUFFER: [u8; 8] = [u8; 8];
// this line is accepted by rustc but gets a big scary error diagnostic
// from rust-analyzer:
let array = &raw mut BUFFER;
// on this line, rust-analyzer insists the unsafe block is unused
// (which is correct on 1.82 but inconsistent with the above)
let array = unsafe { &raw mut BUFFER };

[ChayimFriedman2]

rust-analyzer does not (yet) natively report unused unsafe (so it must come from rustc), and it's also been updated to not require unsafe from &raw [mut] path like rustc, so this is weird. I also cannot reproduce this. Do you have an outdated version of rust-analyzer?

[cbiffle]

I'd be surprised since rustup is managing it via rust-toolchain.toml, but, let me do some testing just to verify. May not happen for a few hours, sorry.

[thejpster]

Rust 1.81:

Rust 1.82:

There's also a typo on the first line (it should be [0u8; 8]) but that doesn't change what I see.

I'm on VS Code 1.94.2 with extension v0.4.2151 (pre-release).

[cbiffle]

Interesting. So with this code: https://github.com/cbiffle/ra-raw-repro

Using rust-analyzer at: /home/cbiffle/.rustup/toolchains/1.82-x86_64-unknown-linux-gnu/bin/rust-analyzer (so not an old version)

I see this:

(it remains if I fix the unused variable warning.)

neovim reports:

rustfmt 1.7.1-stable (f6e511e 2024-10-15)
rustc 1.82.0 (f6e511eec 2024-10-15)
cargo 1.82.0 (8f40fc59f 2024-08-21)

NVIM v0.10.2
Build type: RelWithDebInfo
LuaJIT 2.1.1727870382

[thejpster]

OK, I see that in your repro.

It goes away if I remove the rust-toolchain.toml file.

[thejpster]

I played with the rust-toolchain.toml file, and even if I use this I see the error.

[toolchain]
channel = "stable"

[ChayimFriedman2]

Probably the r-a on rustup is outdated.

[thejpster]

Ah, I see a difference in versions. With the toolchain file, it says Server Version 1.82 in the pop-out, but without a toolchain file it says Server version 0.4.2151-standalone. So ... a toolchain file makes it use the r-a shipped with Rust 1.82 and not whatever the r-a version the extension is bundling? And the version in Rust 1.82 doesn't know about the new syntax in 1.82?

[cbiffle]

My systems don't have bundled rust-analyzers, I only use the one from rustup and avoid relying on ambient default toolchains. So, that may be why I tripped over this.

Probably the r-a on rustup is outdated.

Well, I posted the git rev output from rust-analyzer on rustup above, is it outdated? I'm a user, I don't know the project or release process.

[ChayimFriedman2]

Yeah, it looks like this version just missed the fix (#18003).

CC @lnicola, do we have something to do here?

[ChayimFriedman2]

As a workaround, you can add missing-unsafe to rust-analyzer.diagnostics.disabled.

[Veykril]

We missed the beta cutoff for 1.82 with the fix on our side, so there is little we can do here aside from point people to use the config that was mentioned or using a non rustup rust-analyzer.

Might be a good idea to raise that to the lang team for stabilization requirements to check this kinda stuff as more and more people seem to be relying on rustup releases now. -> raised https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/Stabilization.20requirements.20for.20language.20changes

[workingjubilee]

Might be a good idea to raise that to the lang team for stabilization requirements to check this kinda stuff as more and more people seem to be relying on rustup releases now. -> raised https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/Stabilization.20requirements.20for.20language.20changes

T-lang took note of the PR but did not FCP the change, as it was considered a bug fix and not a stabilization. Thus, asking for this to be added to T-lang's stabilization process has the odd consequence that if the process had already been modified, it would not have been applied.

I merely note this because I would be happy to try to make sure some testing is done, but I would not have had my Big Book of Rust Process open to that particular chapter.

[ChayimFriedman2]

Closing as unactionable from our side.