Standard macros reported as missing-unsafe

[tim3z]

Hi there,

I'm using rust-analyzer (rust-analyzer 996300f4a 2021-08-23 dev) installed with the arch linux rust-analyzer package in Sublime Text 4 with the LSP package and an up to date nightly rust compiler (rustc 1.56.0-nightly (b03ccace5 2021-08-24)). Today, rust-analyzer started reporting this operation is unsafe and requires an unsafe function or block on the dbg!, eprintln! and println! (list probably not exhaustive) macros. Minimal example:

fn main() {
    dbg!(42);
}

I tried downgrading the arch package to last weeks rust-analyzer but that didn't change anything. But apparently, this has something to do with todays nightly because when using rustc 1.56.0-nightly (af140757b 2021-08-22) the issue disappears. However, running cargo check reports no issues.

I'm not quite sure if this is the right place to report this issue, but since cargo check works fine regardless of the compiler version I thought, I'd best start here. I'd be happy to provide additional information if necessary. Is there a way I can make rust-analyzer report the errors on the command line so I can exclude my editor as a potential error source?

[bjorn3]

Maybe rust-analyzer ignores #[allow_internal_unsafe]? It is used on format_args!() since rust-lang/rust#83302.

https://github.com/rust-lang/rust/pull/83302/files#diff-7fdf8ef3b0e02b28e3caa4cc144046f9510df7c8a1f524124f4921601a3d7456R831

[js2xxx]

I've also met with the error. To reproduce it, just create a new executable crate and println!("Hello, world!") will be marked missing-unsafe. The error disappears when executing Ctrl+Shift+B and selecting cargo build in vscode, but appears again after modifying the file.
I'm using rust-analyzer 996300f 2021-08-24 dev and rustc 1.56.0-nightly (b03ccace5 2021-08-24).

[cormacrelf]

This was introduced by a rustc nightly in the last few days, not by a rust-analyzer release. I held rust-analyzer 996300f4a 2021-08-23 stable constant, and used cargo-bisect-rustc. (Edit: I also tried it the other way round, going back through the last bunch of rust-analyzer releases, reproducing this on rustc nightly-2021-08-24 going back months.)

The problem started with nightly-2021-08-24 on rustup. Bisecting found the regression in this commit, specifically from the introduction of the unsafe keyword on the Arguments::new_v1 function here:

rust-lang/rust@de42550#diff-79bafab5831564f0d33567cf953a0c6cb70c66ed5db55a70fb39f485c48858aeR336-R350

---

Hint for cargo-bisect-rustc, which will crash unwrapping an invalid channel name in rust-toolchain.toml if you leave one hanging around at any point during the bisect run:

1. Use function testit() { rustup toolchain link bisector ~/.rustup/toolchains/bisector-$1-aarch64-apple-darwin; echo -e '[toolchain]\nchannel = "bisector"' > rust-toolchain.toml; nvim src/lib.rs; } to avoid editing a rust-toolchain.toml file each time bisect steps
2. Use the --preserve flag to avoid having an invalid channel name (via bisector symlink) in rust-toolchain.toml, which causes cargo-bisect-rustc to crash.
3. Use the --prompt --with-src flags for rust-analyzer interactive use

[bjorn3]

The change that causes this behavior was in rustc, but the root bug is in rust-analyzer: #10022 (comment)

[oxalica]

@bjorn3

Maybe rust-analyzer ignores #[allow_internal_unsafe]?

No. This attribute only by-pass the unsafe_code lint, thus it can use unsafe block when this lint is denied. It doesn't by-pass the usage of unsafe {} on unsafe operations.

The issue here is that we expand the builtin macro format_args to std::fmt::Arguments::new_v1 call:
https://github.com/rust-analyzer/rust-analyzer/blob/793389b61afe9336e40a4cf8f75286ec3ea74582/crates/hir_expand/src/builtin_macro.rs#L229-L240

But std::fmt::Arguments::new_v1 is now an unsafe fn after that PR.

I think simply making the expansion contains an unsafe block would fix it. I'm working on it.

[bjorn3]

Ah, right.