Skip to content
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

Merged
merged 10 commits into from
Apr 6, 2023

Conversation

Veykril
Copy link
Member

@Veykril Veykril commented Mar 29, 2023

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.

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 29, 2023
@lnicola
Copy link
Member

lnicola commented Mar 29, 2023

Maybe let's merge this next Monday so we can put up a warning before it happens.

@Veykril
Copy link
Member Author

Veykril commented Mar 29, 2023

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)

@Veykril
Copy link
Member Author

Veykril commented Mar 29, 2023

Alright, proc-macro-srv tests should work on our CI now I think (with the help of my beloved RUSTC_BOOTSTRAP)

@Veykril
Copy link
Member Author

Veykril commented Mar 30, 2023

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

@Veykril
Copy link
Member Author

Veykril commented Apr 4, 2023

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 🎉

@Veykril Veykril marked this pull request as ready for review April 4, 2023 17:26
@Veykril
Copy link
Member Author

Veykril commented Apr 4, 2023

So I guess now the question remains when we wanna publish this

@Veykril
Copy link
Member Author

Veykril commented Apr 6, 2023

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

Copy link
Member

@lnicola lnicola left a 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.

@lnicola
Copy link
Member

lnicola commented Apr 6, 2023

@bors r+

@bors
Copy link
Contributor

bors commented Apr 6, 2023

📌 Commit 33e649d has been approved by lnicola

It is now in the queue for this repository.

@bors
Copy link
Contributor

bors commented Apr 6, 2023

⌛ Testing commit 33e649d with merge e3e324d...

@bors
Copy link
Contributor

bors commented Apr 6, 2023

☀️ Test successful - checks-actions
Approved by: lnicola
Pushing e3e324d to master...

@bors bors merged commit e3e324d into rust-lang:master Apr 6, 2023
@Veykril Veykril deleted the proc-macro-srv branch April 6, 2023 08:37
@lnicola lnicola changed the title Drop support for non-syroot proc macro ABIs feat: Drop support for non-syroot proc macro ABIs Apr 6, 2023
@@ -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
Copy link
Member

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?

@jonhoo
Copy link
Contributor

jonhoo commented Apr 25, 2023

Should this new feature also be enabled in

let cmd = cmd!(sh, "cargo install --path crates/rust-analyzer --locked --force --features force-always-assert {features...}");
so it gets built when using xtask install too?

@Veykril
Copy link
Member Author

Veykril commented Apr 25, 2023

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

@flodiebold
Copy link
Member

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.

@jonhoo
Copy link
Contributor

jonhoo commented Apr 25, 2023

Ah, I missed that sysroot-abi required nightly to build! That helps explain the discrepancy.

In terms of whether it's necessary, you'll know that better than I do. But internally at $work where we weren't building rust-analyzer with sysroot-abi (since it was recently added), I now have folks running into this error:

msg::Request::ListMacros { .. } => {
msg::Response::ListMacros(Err("server is built without sysroot support".to_owned()))
}
msg::Request::ExpandMacro(..) => msg::Response::ExpandMacro(Err(msg::PanicMessage(
"server is built without sysroot support".to_owned(),
))),

Which suggests that for at least some of the things they're wanting to do this comes back to bite them.

@Veykril
Copy link
Member Author

Veykril commented Apr 25, 2023

Which rust version are you using at $work? If it is < 1.64 then yes, you'll have to build r-a with this feature (and pray that the proc-macro interface hasn't changed since your version, that is the proc-macro-srv might not build on < 1.64 due to API breakage given its unstable)

@flodiebold
Copy link
Member

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

@Veykril
Copy link
Member Author

Veykril commented Apr 25, 2023

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

@flodiebold
Copy link
Member

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?

@Veykril
Copy link
Member Author

Veykril commented Apr 25, 2023

We should probably get rid of the fallback yes, now that we only support the sysroot the fallback makes little sense.

@andrewbanchich
Copy link
Contributor

Which rust version are you using at $work? If it is < 1.64 then yes, you'll have to build r-a with this feature (and pray that the proc-macro interface hasn't changed since your version, that is the proc-macro-srv might not build on < 1.64 due to API breakage given its unstable)

@Veykril 1.69.0

@Veykril
Copy link
Member Author

Veykril commented Apr 25, 2023

Huh, are you setting the proc-macro server path specifically instead of letting it pick the sysroot one?

@andrewbanchich
Copy link
Contributor

Nope, not doing anything fancy. Unless Emacs' lsp-mode is doing that under the hood for some reason.

@jonhoo
Copy link
Contributor

jonhoo commented Apr 25, 2023

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?

@andrewbanchich
Copy link
Contributor

andrewbanchich commented Apr 25, 2023

I uninstalled our internal build, cloned the repo, and installed using cargo xtask install --server and I'm still getting this error.

@Veykril
Copy link
Member Author

Veykril commented Apr 25, 2023

We do build Rust from source though,

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)

@jonhoo
Copy link
Contributor

jonhoo commented Apr 25, 2023

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 rust-toolchain.toml) and a custom build of Rust underlying that. Looking a little deeper here, the proc macro server lives under $sysroot/libexec, so I suspect our custom toolchain just doesn't distribute that subdirectory correctly. I'll do some more digging!

@jonhoo
Copy link
Contributor

jonhoo commented Apr 25, 2023

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 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants