rls no longer builds after rust-lang/rust#91539

[rust-highfive]

Hello, this is your friendly neighborhood mergebot.
After merging PR #91539, I observed that the tool rls no longer builds.
A follow-up PR to the repository https://github.com/rust-lang/rls is needed to fix the fallout.

cc @matthiaskrgr, do you think you would have time to do the follow-up work?
If so, that would be great!

[matthiaskrgr]

This might be due to #91355
rustc-ap-rustc_span v722.0.0 no longer builds:

error[E0635]: unknown feature `thread_local_const_init`
  --> /home/matthias/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/rustc-ap-rustc_span-722.0.0/src/lib.rs:23:12
   |
23 | #![feature(thread_local_const_init)]
   |            ^^^^^^^^^^^^^^^^^^^^^^^

We need a new version I think.
The last published version of https://crates.io/crates/rustc-ap-rustc_span is 5 months old already 🤔
@alexcrichton Can you please check why there are no new rustc-ap versions being published?

[calebcartwright]

alexcrichton Can you please check why there are no new rustc-ap versions being published?

https://github.com/alexcrichton/rustc-auto-publish/actions/workflows/main.yml

This scheduled workflow is disabled because there hasn't been activity in this repository for at least 60 days. Enable this workflow to resume scheduled runs.

TIL scheduled GitHub Action Workflows apparently require regular activity in the repository to keep going 👀

[alexcrichton]

I didn't realize anyone was still using those crates so I disabled the action, I believe it was broken anyway. Does rustfmt and/or other crates still use those crates.io packages? If so I can try to find time to restart the action.

[flip1995]

Racer still uses those crates. And RLS depends on Racer. So without those crates compiling racer with the latest nightly isn't possible, which makes compiling RLS impossible and therefore blocks the sync of RLS back to rust-lang/rust.

[flip1995]

Would it maybe be an option to make racer depend on rustc-dev to compile instead of publishing AP crates?

[calebcartwright]

Does rustfmt and/or other crates still use those crates.io packages?

We stopped using them in rustfmt a while ago and I can't imagine a scenario where we'd switch back.

Agreed on racer, which AIUI is the last true direct consumer of those crates. However, it's also in maintenance mode and those crates only get bumped in racer when a racer consumer needs them to be bumped.

[alexcrichton]

Ah ok. In that case if this is purely for something in maintenance mode I think my own personal tenure in maintaining these crates is over with, so I would prefer to hand over the reins to someone else. Would someone be willing to volunteer to take over these crates?

[Mark-Simulacrum]

@alexcrichton let's sync up on #t-infra on Zulip -- I think it makes sense to move these crates into infra control/publication.

[flip1995]

Let's wait if Racer can move over to rustc-dev racer-rust/racer#1174. If so, there shouldn't be a need to keep maintaining rustc-ap crates at all. Looking at the dependents on crates.io, there really is only racer, the rustc-ap crates themselves and rustfmt-nightly (which by now uses rustc-dev).

[calebcartwright]

#88867 has some relevant considerations as well. One way or another I think the AP crates need to be accounted for as per the accepted RFC, though it certainly would be a simpler story if they no longer need to be updated/published

[alexcrichton]

Happy to coordinate as necessary, just let me know!

[ThatAnonyG]

Over a month now. Is this gonna be fixed?

[mati865]

@ThatAnonyG it's blocked on racer-rust/racer#1174