2020-03-26 21:12:17 +00:00
|
|
|
//! Handle process life-time and message passing for proc-macro client
|
|
|
|
|
2020-03-26 20:26:34 +00:00
|
|
|
use std::{
|
2020-08-12 14:46:20 +00:00
|
|
|
io::{self, BufRead, BufReader, Write},
|
2021-07-08 14:40:14 +00:00
|
|
|
process::{Child, ChildStdin, ChildStdout, Command, Stdio},
|
2020-03-26 20:26:34 +00:00
|
|
|
};
|
|
|
|
|
2021-07-17 13:54:48 +00:00
|
|
|
use paths::{AbsPath, AbsPathBuf};
|
2021-02-01 19:24:09 +00:00
|
|
|
use stdx::JodChild;
|
2020-08-12 14:46:20 +00:00
|
|
|
|
|
|
|
use crate::{
|
2023-02-13 11:55:14 +00:00
|
|
|
msg::{Message, Request, Response, CURRENT_API_VERSION},
|
internal: cleanup proc macro server error handlig
When dealing with proc macros, there are two very different kinds of
errors:
* first, usual errors of "proc macro panicked on this particular input"
* second, the proc macro server might day if the user, eg, kills it
First kind of errors are expected and are a normal output, while the
second kind are genuine IO-errors.
For this reason, we use a curious nested result here: `Result<Result<T,
E1>, E2>` pattern, which is 100% inspired by http://sled.rs/errors.html
2021-08-31 16:01:39 +00:00
|
|
|
ProcMacroKind, ServerError,
|
2020-08-12 14:46:20 +00:00
|
|
|
};
|
|
|
|
|
2021-07-08 15:10:35 +00:00
|
|
|
#[derive(Debug)]
|
2020-03-26 20:26:34 +00:00
|
|
|
pub(crate) struct ProcMacroProcessSrv {
|
2021-09-15 18:22:06 +00:00
|
|
|
_process: Process,
|
2021-07-12 13:19:53 +00:00
|
|
|
stdin: ChildStdin,
|
|
|
|
stdout: BufReader<ChildStdout>,
|
2023-02-13 11:55:14 +00:00
|
|
|
version: u32,
|
2020-03-26 20:26:34 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
impl ProcMacroProcessSrv {
|
2023-06-05 09:04:23 +00:00
|
|
|
pub(crate) fn run(process_path: AbsPathBuf) -> io::Result<ProcMacroProcessSrv> {
|
2023-02-13 11:55:14 +00:00
|
|
|
let create_srv = |null_stderr| {
|
2023-06-05 09:04:23 +00:00
|
|
|
let mut process = Process::run(process_path.clone(), null_stderr)?;
|
2023-02-13 11:55:14 +00:00
|
|
|
let (stdin, stdout) = process.stdio().expect("couldn't access child stdio");
|
|
|
|
|
|
|
|
io::Result::Ok(ProcMacroProcessSrv { _process: process, stdin, stdout, version: 0 })
|
|
|
|
};
|
|
|
|
let mut srv = create_srv(true)?;
|
|
|
|
tracing::info!("sending version check");
|
|
|
|
match srv.version_check() {
|
|
|
|
Ok(v) if v > CURRENT_API_VERSION => Err(io::Error::new(
|
|
|
|
io::ErrorKind::Other,
|
|
|
|
format!(
|
|
|
|
"proc-macro server's api version ({}) is newer than rust-analyzer's ({})",
|
|
|
|
v, CURRENT_API_VERSION
|
|
|
|
),
|
|
|
|
)),
|
|
|
|
Ok(v) => {
|
|
|
|
tracing::info!("got version {v}");
|
|
|
|
srv = create_srv(false)?;
|
|
|
|
srv.version = v;
|
|
|
|
Ok(srv)
|
|
|
|
}
|
|
|
|
Err(e) => {
|
|
|
|
tracing::info!(%e, "proc-macro version check failed, restarting and assuming version 0");
|
|
|
|
create_srv(false)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2021-07-08 14:40:14 +00:00
|
|
|
|
2023-06-05 09:04:23 +00:00
|
|
|
pub(crate) fn version(&self) -> u32 {
|
|
|
|
self.version
|
|
|
|
}
|
|
|
|
|
2023-02-13 11:55:14 +00:00
|
|
|
pub(crate) fn version_check(&mut self) -> Result<u32, ServerError> {
|
|
|
|
let request = Request::ApiVersionCheck {};
|
|
|
|
let response = self.send_task(request)?;
|
2021-07-08 14:40:14 +00:00
|
|
|
|
2023-02-13 11:55:14 +00:00
|
|
|
match response {
|
|
|
|
Response::ApiVersionCheck(version) => Ok(version),
|
|
|
|
Response::ExpandMacro { .. } | Response::ListMacros { .. } => {
|
|
|
|
Err(ServerError { message: "unexpected response".to_string(), io: None })
|
|
|
|
}
|
|
|
|
}
|
2020-03-26 20:26:34 +00:00
|
|
|
}
|
|
|
|
|
2020-11-02 12:13:32 +00:00
|
|
|
pub(crate) fn find_proc_macros(
|
2021-07-12 13:19:53 +00:00
|
|
|
&mut self,
|
2021-07-17 13:54:48 +00:00
|
|
|
dylib_path: &AbsPath,
|
internal: cleanup proc macro server error handlig
When dealing with proc macros, there are two very different kinds of
errors:
* first, usual errors of "proc macro panicked on this particular input"
* second, the proc macro server might day if the user, eg, kills it
First kind of errors are expected and are a normal output, while the
second kind are genuine IO-errors.
For this reason, we use a curious nested result here: `Result<Result<T,
E1>, E2>` pattern, which is 100% inspired by http://sled.rs/errors.html
2021-08-31 16:01:39 +00:00
|
|
|
) -> Result<Result<Vec<(String, ProcMacroKind)>, String>, ServerError> {
|
|
|
|
let request = Request::ListMacros { dylib_path: dylib_path.to_path_buf().into() };
|
2020-03-26 20:26:34 +00:00
|
|
|
|
internal: cleanup proc macro server error handlig
When dealing with proc macros, there are two very different kinds of
errors:
* first, usual errors of "proc macro panicked on this particular input"
* second, the proc macro server might day if the user, eg, kills it
First kind of errors are expected and are a normal output, while the
second kind are genuine IO-errors.
For this reason, we use a curious nested result here: `Result<Result<T,
E1>, E2>` pattern, which is 100% inspired by http://sled.rs/errors.html
2021-08-31 16:01:39 +00:00
|
|
|
let response = self.send_task(request)?;
|
2020-03-26 20:26:34 +00:00
|
|
|
|
internal: cleanup proc macro server error handlig
When dealing with proc macros, there are two very different kinds of
errors:
* first, usual errors of "proc macro panicked on this particular input"
* second, the proc macro server might day if the user, eg, kills it
First kind of errors are expected and are a normal output, while the
second kind are genuine IO-errors.
For this reason, we use a curious nested result here: `Result<Result<T,
E1>, E2>` pattern, which is 100% inspired by http://sled.rs/errors.html
2021-08-31 16:01:39 +00:00
|
|
|
match response {
|
|
|
|
Response::ListMacros(it) => Ok(it),
|
2023-02-13 11:55:14 +00:00
|
|
|
Response::ExpandMacro { .. } | Response::ApiVersionCheck { .. } => {
|
internal: cleanup proc macro server error handlig
When dealing with proc macros, there are two very different kinds of
errors:
* first, usual errors of "proc macro panicked on this particular input"
* second, the proc macro server might day if the user, eg, kills it
First kind of errors are expected and are a normal output, while the
second kind are genuine IO-errors.
For this reason, we use a curious nested result here: `Result<Result<T,
E1>, E2>` pattern, which is 100% inspired by http://sled.rs/errors.html
2021-08-31 16:01:39 +00:00
|
|
|
Err(ServerError { message: "unexpected response".to_string(), io: None })
|
2020-03-26 20:26:34 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
internal: cleanup proc macro server error handlig
When dealing with proc macros, there are two very different kinds of
errors:
* first, usual errors of "proc macro panicked on this particular input"
* second, the proc macro server might day if the user, eg, kills it
First kind of errors are expected and are a normal output, while the
second kind are genuine IO-errors.
For this reason, we use a curious nested result here: `Result<Result<T,
E1>, E2>` pattern, which is 100% inspired by http://sled.rs/errors.html
2021-08-31 16:01:39 +00:00
|
|
|
|
|
|
|
pub(crate) fn send_task(&mut self, req: Request) -> Result<Response, ServerError> {
|
|
|
|
let mut buf = String::new();
|
|
|
|
send_request(&mut self.stdin, &mut self.stdout, req, &mut buf)
|
|
|
|
}
|
2020-03-26 20:26:34 +00:00
|
|
|
}
|
|
|
|
|
2021-07-08 14:40:14 +00:00
|
|
|
#[derive(Debug)]
|
2020-04-20 21:22:17 +00:00
|
|
|
struct Process {
|
2021-02-01 19:24:09 +00:00
|
|
|
child: JodChild,
|
2020-04-20 21:22:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
impl Process {
|
2023-06-05 09:04:23 +00:00
|
|
|
fn run(path: AbsPathBuf, null_stderr: bool) -> io::Result<Process> {
|
|
|
|
let child = JodChild(mk_child(&path, null_stderr)?);
|
2020-12-04 18:59:58 +00:00
|
|
|
Ok(Process { child })
|
2020-04-20 21:22:17 +00:00
|
|
|
}
|
|
|
|
|
2021-07-08 14:40:14 +00:00
|
|
|
fn stdio(&mut self) -> Option<(ChildStdin, BufReader<ChildStdout>)> {
|
2020-04-20 21:22:17 +00:00
|
|
|
let stdin = self.child.stdin.take()?;
|
|
|
|
let stdout = self.child.stdout.take()?;
|
|
|
|
let read = BufReader::new(stdout);
|
|
|
|
|
|
|
|
Some((stdin, read))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-06-05 09:04:23 +00:00
|
|
|
fn mk_child(path: &AbsPath, null_stderr: bool) -> io::Result<Child> {
|
2021-07-17 13:54:48 +00:00
|
|
|
Command::new(path.as_os_str())
|
2022-07-26 09:53:50 +00:00
|
|
|
.env("RUST_ANALYZER_INTERNALS_DO_NOT_USE", "this is unstable")
|
2020-04-20 21:22:17 +00:00
|
|
|
.stdin(Stdio::piped())
|
|
|
|
.stdout(Stdio::piped())
|
2023-02-13 11:55:14 +00:00
|
|
|
.stderr(if null_stderr { Stdio::null() } else { Stdio::inherit() })
|
2020-04-20 21:22:17 +00:00
|
|
|
.spawn()
|
|
|
|
}
|
|
|
|
|
2020-03-28 10:12:51 +00:00
|
|
|
fn send_request(
|
2020-03-26 20:26:34 +00:00
|
|
|
mut writer: &mut impl Write,
|
|
|
|
mut reader: &mut impl BufRead,
|
2020-03-28 10:12:51 +00:00
|
|
|
req: Request,
|
2021-03-23 19:47:08 +00:00
|
|
|
buf: &mut String,
|
internal: cleanup proc macro server error handlig
When dealing with proc macros, there are two very different kinds of
errors:
* first, usual errors of "proc macro panicked on this particular input"
* second, the proc macro server might day if the user, eg, kills it
First kind of errors are expected and are a normal output, while the
second kind are genuine IO-errors.
For this reason, we use a curious nested result here: `Result<Result<T,
E1>, E2>` pattern, which is 100% inspired by http://sled.rs/errors.html
2021-08-31 16:01:39 +00:00
|
|
|
) -> Result<Response, ServerError> {
|
|
|
|
req.write(&mut writer)
|
|
|
|
.map_err(|err| ServerError { message: "failed to write request".into(), io: Some(err) })?;
|
|
|
|
let res = Response::read(&mut reader, buf)
|
|
|
|
.map_err(|err| ServerError { message: "failed to read response".into(), io: Some(err) })?;
|
|
|
|
res.ok_or_else(|| ServerError { message: "server exited".into(), io: None })
|
2020-03-26 20:26:34 +00:00
|
|
|
}
|