Rust 2024 and 1.85

[BenjaminBrienen]

No description provided.

[BenjaminBrienen]

I hope this is more reviewable than the last one! I understand that this will not be merged until #18964 is landed. Please just block this until then. I will fix the merge conflicts afterward. :)

[BenjaminBrienen]

This test fails for me, and I don't know why:

test tests::smoke_test_real_sysroot_cargo ... FAILED

failures:

---- tests::smoke_test_real_sysroot_cargo stdout ----

thread 'tests::smoke_test_real_sysroot_cargo' panicked at crates/base-db/src/input.rs:527:74:
no entry found for key

[ChayimFriedman2]

It's not you. #19214.

[Veykril]

Gonna repeat myself just to be safe but this will have to land after #18964

Edit: Ah I see you raised that in a comment already, sorry :)

[BenjaminBrienen]

git rebase had a bad time with the imports, so I fixed it up in the last commit

[BenjaminBrienen]

The CI error baffles me. Is that a bug in the action?

[lnicola]

The new rustup that just came out has some breaking changes, but I don't see anything that would affect this. However, at:

https://github.com/rust-lang/rust-analyzer/actions/runs/13663331790/workflow?pr=19236#L70-L71

Can you try rustup +nightly component add rustfmt? If it works, we could also try to merge it into the command above as rustup toolchain install nightly --profile minimal --components rustfmt.

[lnicola]

I went down the second route in #19286.

[BenjaminBrienen]

Some functions are no longer unsafe on nightly:
https://doc.rust-lang.org/stable/core/arch/arm/fn.vshrn_n_u16.html
https://doc.rust-lang.org/nightly/core/arch/arm/fn.vshrn_n_u16.html

[BenjaminBrienen]

@lnicola this PR is not about updating to rust 1.87, so what should I do about the CI failure? Why is CI for PRs using rust nightly anyway?

[ChayimFriedman2]

CI uses nightly when the proc macro server is touched, because it must build on nightly. You can #[allow(unused_unsafe)] for now.

[BenjaminBrienen]

If I do that, then we will miss that lint when it becomes relevant in stable. Is there a way to only expect a lint if compiling if the nightly toolchain is being used? I want this lint to trigger when the function is no longer unsafe in stable.

I think we should add an internal feature called nightly which allows us to expect lint, but only on nightly by using #[cfg_attr(nightly, ...)]. This issue will come up whenever there is a new lint in nightly that affects r-a, so a robust solution is needed.

[Veykril]

We should probably have CI have a separate job for the proc-macro server instead. There is little reason for us to run the entire codebase on nightly

[BenjaminBrienen]

Nice, thanks. I'll let you handle that.

[Veykril]

Put up #19328

[BenjaminBrienen]

Put up #19328

That did the trick. Thanks!

[BenjaminBrienen]

Should be unblocked now

[Veykril]

Ah those failures are because the salsa pr didn't trigger the proc macro test suite, we should add the span crate to the condition.

Either wya those test outputs need to be updated

[BenjaminBrienen]

Should I do anything?