-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Drop support for non-syroot proc macro ABIs #14432
Conversation
Maybe let's merge this next Monday so we can put up a warning before it happens. |
Certainly, I am not proposing to merge it this week, I am also fine with waiting a few more weeks. I just wanted to get this out of the way and see what changes (and if we can make the proc-macro tests work on our repo somehow) |
Alright, proc-macro-srv tests should work on our CI now I think (with the help of my beloved |
Something breaks on mac here but I don't know what or why and since I don't have access to a mac myself I am not able to debug this ... |
Well, apparently it was buildscripts being a problem for the platform (I imagine its an architecture mismatch, iirc mac had some weird things with that). CI now works though 🎉 |
So I guess now the question remains when we wanna publish this |
So, I wonder if we need to announce this at all, we already didn't do that the last time which dropped a lot of versions, while this one effectively drops one minor rust version only |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, the sysroot server was added in 1.64. I think we can merge this.
@bors r+ |
☀️ Test successful - checks-actions |
@@ -24,6 +24,9 @@ jobs: | |||
runs-on: ${{ matrix.os }} | |||
env: | |||
CC: deny_c | |||
# we want to build r-a on stable to check that it keeps building on stable, | |||
# but we also want to test our proc-macro-srv which depends on nightly features | |||
RUSTC_BOOTSTRAP: 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you can set RUSTC_BOOTSTRAP
to a set of crates like RUSTC_BOOTSTRAP=proc-macro-srv
?
Should this new feature also be enabled in rust-analyzer/xtask/src/install.rs Line 139 in 943d2a8
xtask install too?
|
That would force people to use a nightly toolchain for install to work since the proc-macro server requires nightly features, so I don't think we want that to be appended there by default |
It's also not necessary, right? It only needs to be enabled when building the proc macro server, which you only need to do when building rustc yourself, not if you just want to build rust-analyzer. |
Ah, I missed that In terms of whether it's necessary, you'll know that better than I do. But internally at rust-analyzer/crates/proc-macro-srv-cli/src/lib.rs Lines 32 to 37 in 943d2a8
Which suggests that for at least some of the things they're wanting to do this comes back to bite them. |
Which rust version are you using at |
That code lives inside the proc macro server, and unless I'm misunderstanding how this works now (which is possible), you should be running the proc macro server bundled with your rustc installation. So you should only run into this error if you're using a sysroot that doesn't have the bundled proc macro server, which should only happen if your rustc is too old or you built it yourself, I think. (I guess we fall back to using rust-analyzer as the proc macro server, which is how you then get the error message?) |
Yes, if we can't find a sysroot server we fall back to using the r-a server binary which I believe is built without the feature when publishing? (which makes sense fwiw, but I am actually not 100% sure that's the case) |
I wonder if that fallback still makes sense then? I guess it can be useful if you built RA with the feature, but it's also just likely to break then if you're not using the exact right rustc version. Maybe we should just give an error message on the server side instead? |
We should probably get rid of the fallback yes, now that we only support the sysroot the fallback makes little sense. |
@Veykril 1.69.0 |
Huh, are you setting the proc-macro server path specifically instead of letting it pick the sysroot one? |
Nope, not doing anything fancy. Unless Emacs' |
We do build Rust from source though, so if there's a particular way in which we have to configure the Rust build to get it to build the proc macro server, then we may not be doing that? Does this assume that a particular rustup component is installed for example? |
I uninstalled our internal build, cloned the repo, and installed using |
Does this mean you are using a custom toolchain? That might be the problem, I am not sure if that will build the proc-macro server by default. Also seeing a server log would be nice, it might have some extra info on what server is being used. (nevertheless, this change here should not have impacted you. From what you've described, you should've had different problems alltogether prior to this) |
Yeah, there's a custom toolchain in use here. In more ways than one — it's both a custom rustup toolchain (a "path" toolchain in |
Seems that with rust-lang/rust@11e002a (which landed in 1.69), the proc macro server is no longer always built, and needs to be explicitly listed in the tools list for any custom from source builds of Rust 👍 |
This makes some bigger changes to how we handle the proc-macro-srv things, for one it is now an empty crate if built without the
sysroot-abi
feature, this simplifies some things dropping the need to put the feature cfg in various places. The cli wrapper now actually depends on the server, instead of being part of the server that is just exported, that way we can have a true dummy server that just errors on each request if no sysroot support was specified.