-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
Mark rust-analyzer
as a host-only tool
#103246
Conversation
All tools meant to be shipped with host toolchains only should be marked as `ONLY_HOSTS = true`, but rust-analyzer was marked as `ONLY_HOSTS = false` incorrectly. This meant that bootstrap attempted to build rust-analyzer for cross-compilation-only targets, causing errors because libstd is not present on some of them. It will still be possible to cross-compile rust-analyzer by passing a different --host flag to ./x, like you can cross-compile other tools.
(rust-highfive has picked a reviewer for you, use r? to override) |
@@ -742,7 +742,7 @@ pub struct RustAnalyzerProcMacroSrv { | |||
impl Step for RustAnalyzerProcMacroSrv { | |||
type Output = Option<PathBuf>; | |||
const DEFAULT: bool = true; | |||
const ONLY_HOSTS: bool = false; | |||
const ONLY_HOSTS: bool = true; |
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'm not sure this is right. Isn't this libproc_macro but for rust-analyzer? IOW, shouldn't it be shipped whenever we ship std?
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.
No, we should ship this wherever we ship a host compiler. The binary provides a stable interface between rust-analyzer
and the current compiler's proc macro implementation, so there should be no point in shipping it outside of host toolchains.
@bors r+ rollup |
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#103211 (rustdoc: remove class name `location` from sidebar sibling nav) - rust-lang#103223 (Use already checked RHS ty for LHS deref suggestions) - rust-lang#103237 (Clean up codeblock-tooltip rustdoc-gui test) - rust-lang#103239 (Allow #[unstable] impls for fn() with unstable abi.) - rust-lang#103246 (Mark `rust-analyzer` as a host-only tool) - rust-lang#103257 (rustdoc: move `setting-line` color CSS to settings.css) - rust-lang#103258 (Make miri read_dir test a little more robust) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#103211 (rustdoc: remove class name `location` from sidebar sibling nav) - rust-lang#103223 (Use already checked RHS ty for LHS deref suggestions) - rust-lang#103237 (Clean up codeblock-tooltip rustdoc-gui test) - rust-lang#103239 (Allow #[unstable] impls for fn() with unstable abi.) - rust-lang#103246 (Mark `rust-analyzer` as a host-only tool) - rust-lang#103257 (rustdoc: move `setting-line` color CSS to settings.css) - rust-lang#103258 (Make miri read_dir test a little more robust) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
All tools meant to be shipped with host toolchains only should be marked as
ONLY_HOSTS = true
, but rust-analyzer was marked asONLY_HOSTS = false
incorrectly. This meant that bootstrap attempted to build rust-analyzer for cross-compilation-only targets, causing errors because libstd is not present on some of them.It will still be possible to cross-compile rust-analyzer by passing a different
--host
flag to./x
, like you can cross-compile other tools.The problem can be reproduced by running: