2020-03-26 16:12:17 -05:00
|
|
|
//! Handle process life-time and message passing for proc-macro client
|
|
|
|
|
2020-03-26 15:26:34 -05:00
|
|
|
use std::{
|
2024-01-08 04:40:27 -06:00
|
|
|
io::{self, BufRead, BufReader, Read, Write},
|
2021-07-08 09:40:14 -05:00
|
|
|
process::{Child, ChildStdin, ChildStdout, Command, Stdio},
|
2024-01-08 04:40:27 -06:00
|
|
|
sync::Arc,
|
2020-03-26 15:26:34 -05:00
|
|
|
};
|
|
|
|
|
2021-07-17 08:54:48 -05:00
|
|
|
use paths::{AbsPath, AbsPathBuf};
|
2021-02-01 13:24:09 -06:00
|
|
|
use stdx::JodChild;
|
2020-08-12 09:46:20 -05:00
|
|
|
|
|
|
|
use crate::{
|
2023-12-11 05:16:12 -06:00
|
|
|
msg::{Message, Request, Response, SpanMode, CURRENT_API_VERSION, RUST_ANALYZER_SPAN_SUPPORT},
|
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 11:01:39 -05:00
|
|
|
ProcMacroKind, ServerError,
|
2020-08-12 09:46:20 -05:00
|
|
|
};
|
|
|
|
|
2021-07-08 10:10:35 -05:00
|
|
|
#[derive(Debug)]
|
2020-03-26 15:26:34 -05:00
|
|
|
pub(crate) struct ProcMacroProcessSrv {
|
2024-01-08 04:40:27 -06:00
|
|
|
process: Process,
|
2021-07-12 08:19:53 -05:00
|
|
|
stdin: ChildStdin,
|
|
|
|
stdout: BufReader<ChildStdout>,
|
2024-01-08 04:40:27 -06:00
|
|
|
/// Populated when the server exits.
|
|
|
|
server_exited: Option<ServerError>,
|
2023-02-01 04:04:20 -06:00
|
|
|
version: u32,
|
2023-12-11 05:16:12 -06:00
|
|
|
mode: SpanMode,
|
2020-03-26 15:26:34 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
impl ProcMacroProcessSrv {
|
2023-04-26 01:06:15 -05:00
|
|
|
pub(crate) fn run(process_path: AbsPathBuf) -> io::Result<ProcMacroProcessSrv> {
|
2023-02-09 02:46:36 -06:00
|
|
|
let create_srv = |null_stderr| {
|
2023-04-26 01:06:15 -05:00
|
|
|
let mut process = Process::run(process_path.clone(), null_stderr)?;
|
2023-02-01 04:04:20 -06:00
|
|
|
let (stdin, stdout) = process.stdio().expect("couldn't access child stdio");
|
2021-07-08 09:40:14 -05:00
|
|
|
|
2023-12-11 05:16:12 -06:00
|
|
|
io::Result::Ok(ProcMacroProcessSrv {
|
2024-01-08 04:40:27 -06:00
|
|
|
process,
|
2023-12-11 05:16:12 -06:00
|
|
|
stdin,
|
|
|
|
stdout,
|
2024-01-08 04:40:27 -06:00
|
|
|
server_exited: None,
|
2023-12-11 05:16:12 -06:00
|
|
|
version: 0,
|
|
|
|
mode: SpanMode::Id,
|
|
|
|
})
|
2023-02-01 04:04:20 -06:00
|
|
|
};
|
2023-02-09 02:46:36 -06:00
|
|
|
let mut srv = create_srv(true)?;
|
2023-02-01 04:04:20 -06:00
|
|
|
tracing::info!("sending version check");
|
|
|
|
match srv.version_check() {
|
2023-02-03 03:38:38 -06:00
|
|
|
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
|
|
|
|
),
|
|
|
|
)),
|
2023-02-01 04:04:20 -06:00
|
|
|
Ok(v) => {
|
|
|
|
tracing::info!("got version {v}");
|
2023-02-09 02:46:36 -06:00
|
|
|
srv = create_srv(false)?;
|
2023-02-01 04:04:20 -06:00
|
|
|
srv.version = v;
|
2023-12-11 05:16:12 -06:00
|
|
|
if srv.version > RUST_ANALYZER_SPAN_SUPPORT {
|
|
|
|
if let Ok(mode) = srv.enable_rust_analyzer_spans() {
|
|
|
|
srv.mode = mode;
|
|
|
|
}
|
|
|
|
}
|
2023-02-01 04:04:20 -06:00
|
|
|
Ok(srv)
|
|
|
|
}
|
|
|
|
Err(e) => {
|
|
|
|
tracing::info!(%e, "proc-macro version check failed, restarting and assuming version 0");
|
2023-02-09 02:46:36 -06:00
|
|
|
create_srv(false)
|
2023-02-01 04:04:20 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2021-07-08 09:40:14 -05:00
|
|
|
|
2023-04-14 03:34:41 -05:00
|
|
|
pub(crate) fn version(&self) -> u32 {
|
|
|
|
self.version
|
|
|
|
}
|
|
|
|
|
2023-02-01 04:04:20 -06:00
|
|
|
pub(crate) fn version_check(&mut self) -> Result<u32, ServerError> {
|
|
|
|
let request = Request::ApiVersionCheck {};
|
|
|
|
let response = self.send_task(request)?;
|
|
|
|
|
|
|
|
match response {
|
|
|
|
Response::ApiVersionCheck(version) => Ok(version),
|
2024-02-09 09:38:39 -06:00
|
|
|
_ => Err(ServerError { message: "unexpected response".to_owned(), io: None }),
|
2023-12-11 05:16:12 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
fn enable_rust_analyzer_spans(&mut self) -> Result<SpanMode, ServerError> {
|
2023-12-22 03:35:10 -06:00
|
|
|
let request = Request::SetConfig(crate::msg::ServerConfig {
|
|
|
|
span_mode: crate::msg::SpanMode::RustAnalyzer,
|
|
|
|
});
|
2023-12-11 05:16:12 -06:00
|
|
|
let response = self.send_task(request)?;
|
|
|
|
|
|
|
|
match response {
|
2023-12-22 03:35:10 -06:00
|
|
|
Response::SetConfig(crate::msg::ServerConfig { span_mode }) => Ok(span_mode),
|
2024-02-09 09:38:39 -06:00
|
|
|
_ => Err(ServerError { message: "unexpected response".to_owned(), io: None }),
|
2023-02-01 04:04:20 -06:00
|
|
|
}
|
2020-03-26 15:26:34 -05:00
|
|
|
}
|
|
|
|
|
2020-11-02 06:13:32 -06:00
|
|
|
pub(crate) fn find_proc_macros(
|
2021-07-12 08:19:53 -05:00
|
|
|
&mut self,
|
2021-07-17 08:54:48 -05: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 11:01:39 -05:00
|
|
|
) -> Result<Result<Vec<(String, ProcMacroKind)>, String>, ServerError> {
|
|
|
|
let request = Request::ListMacros { dylib_path: dylib_path.to_path_buf().into() };
|
2020-03-26 15:26:34 -05: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 11:01:39 -05:00
|
|
|
let response = self.send_task(request)?;
|
2020-03-26 15:26:34 -05: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 11:01:39 -05:00
|
|
|
match response {
|
|
|
|
Response::ListMacros(it) => Ok(it),
|
2024-02-09 09:38:39 -06:00
|
|
|
_ => Err(ServerError { message: "unexpected response".to_owned(), io: None }),
|
2020-03-26 15:26:34 -05: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 11:01:39 -05:00
|
|
|
|
|
|
|
pub(crate) fn send_task(&mut self, req: Request) -> Result<Response, ServerError> {
|
2024-01-08 04:40:27 -06:00
|
|
|
if let Some(server_error) = &self.server_exited {
|
|
|
|
return Err(server_error.clone());
|
|
|
|
}
|
|
|
|
|
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 11:01:39 -05:00
|
|
|
let mut buf = String::new();
|
2024-01-08 04:40:27 -06:00
|
|
|
send_request(&mut self.stdin, &mut self.stdout, req, &mut buf).map_err(|e| {
|
|
|
|
if e.io.as_ref().map(|it| it.kind()) == Some(io::ErrorKind::BrokenPipe) {
|
|
|
|
match self.process.child.try_wait() {
|
|
|
|
Ok(None) => e,
|
|
|
|
Ok(Some(status)) => {
|
|
|
|
let mut msg = String::new();
|
|
|
|
if !status.success() {
|
|
|
|
if let Some(stderr) = self.process.child.stderr.as_mut() {
|
|
|
|
_ = stderr.read_to_string(&mut msg);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
let server_error = ServerError {
|
|
|
|
message: format!("server exited with {status}: {msg}"),
|
|
|
|
io: None,
|
|
|
|
};
|
|
|
|
self.server_exited = Some(server_error.clone());
|
|
|
|
server_error
|
|
|
|
}
|
|
|
|
Err(_) => e,
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
e
|
|
|
|
}
|
|
|
|
})
|
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 11:01:39 -05:00
|
|
|
}
|
2020-03-26 15:26:34 -05:00
|
|
|
}
|
|
|
|
|
2021-07-08 09:40:14 -05:00
|
|
|
#[derive(Debug)]
|
2020-04-20 16:22:17 -05:00
|
|
|
struct Process {
|
2021-02-01 13:24:09 -06:00
|
|
|
child: JodChild,
|
2020-04-20 16:22:17 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
impl Process {
|
2023-04-26 01:06:15 -05:00
|
|
|
fn run(path: AbsPathBuf, null_stderr: bool) -> io::Result<Process> {
|
|
|
|
let child = JodChild(mk_child(&path, null_stderr)?);
|
2020-12-04 12:59:58 -06:00
|
|
|
Ok(Process { child })
|
2020-04-20 16:22:17 -05:00
|
|
|
}
|
|
|
|
|
2021-07-08 09:40:14 -05:00
|
|
|
fn stdio(&mut self) -> Option<(ChildStdin, BufReader<ChildStdout>)> {
|
2020-04-20 16:22:17 -05:00
|
|
|
let stdin = self.child.stdin.take()?;
|
|
|
|
let stdout = self.child.stdout.take()?;
|
|
|
|
let read = BufReader::new(stdout);
|
|
|
|
|
|
|
|
Some((stdin, read))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-04-26 01:06:15 -05:00
|
|
|
fn mk_child(path: &AbsPath, null_stderr: bool) -> io::Result<Child> {
|
2024-01-08 09:28:18 -06:00
|
|
|
let mut cmd = Command::new(path.as_os_str());
|
|
|
|
cmd.env("RUST_ANALYZER_INTERNALS_DO_NOT_USE", "this is unstable")
|
2020-04-20 16:22:17 -05:00
|
|
|
.stdin(Stdio::piped())
|
|
|
|
.stdout(Stdio::piped())
|
2024-01-08 09:28:18 -06:00
|
|
|
.stderr(if null_stderr { Stdio::null() } else { Stdio::inherit() });
|
|
|
|
if cfg!(windows) {
|
|
|
|
let mut path_var = std::ffi::OsString::new();
|
|
|
|
path_var.push(path.parent().unwrap().parent().unwrap().as_os_str());
|
|
|
|
path_var.push("\\bin;");
|
|
|
|
path_var.push(std::env::var_os("PATH").unwrap_or_default());
|
|
|
|
cmd.env("PATH", path_var);
|
|
|
|
}
|
|
|
|
cmd.spawn()
|
2020-04-20 16:22:17 -05:00
|
|
|
}
|
|
|
|
|
2020-03-28 05:12:51 -05:00
|
|
|
fn send_request(
|
2020-03-26 15:26:34 -05:00
|
|
|
mut writer: &mut impl Write,
|
|
|
|
mut reader: &mut impl BufRead,
|
2020-03-28 05:12:51 -05:00
|
|
|
req: Request,
|
2021-03-23 14:47:08 -05: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 11:01:39 -05:00
|
|
|
) -> Result<Response, ServerError> {
|
2024-01-08 04:40:27 -06:00
|
|
|
req.write(&mut writer).map_err(|err| ServerError {
|
|
|
|
message: "failed to write request".into(),
|
|
|
|
io: Some(Arc::new(err)),
|
|
|
|
})?;
|
|
|
|
let res = Response::read(&mut reader, buf).map_err(|err| ServerError {
|
|
|
|
message: "failed to read response".into(),
|
|
|
|
io: Some(Arc::new(err)),
|
|
|
|
})?;
|
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 11:01:39 -05:00
|
|
|
res.ok_or_else(|| ServerError { message: "server exited".into(), io: None })
|
2020-03-26 15:26:34 -05:00
|
|
|
}
|