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. :)

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

It's not you. #19214.

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 :)

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

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

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.

I went down the second route in #19286.

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

@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?

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

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.

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

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

Put up #19328

Put up #19328

That did the trick. Thanks!

Should be unblocked now

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

Should I do anything?

Should I do anything?

As #19337 updated the proc macro test, I think that rebasing and formatting would suffice.

I can probably do it tonight

I'll check in a bit to see if CI passed, but I think that should be it.

This exists so I'm not sure why it says that it doesn't

 techn0@IO  ~/source/rust-analyzer   rust-2024-and-1.85  cargo check
    Blocking waiting for file lock on build directory
    Checking span v0.0.0 (/home/techn0/source/rust-analyzer/crates/span)
error[E0599]: no variant or associated item named `from_u32` found for enum `Edition` in the current scope
   --> crates/span/src/hygiene.rs:233:33
    |
233 |                 return Edition::from_u32(SyntaxContext::MAX_ID - self.0.as_u32());
    |                                 ^^^^^^^^ variant or associated item not found in `Edition`
    |
help: there is an associated function `from` with a similar name
    |
233 |                 return Edition::from(SyntaxContext::MAX_ID - self.0.as_u32());
    |                                 ~~~~

For more information about this error, try `rustc --explain E0599`.
error: could not compile `span` (lib) due to 1 previous error

The error doesn't happen after I cargo clean, so we're all good to go.