2020-03-18 07:56:46 -05:00
|
|
|
//! Client-side Proc-Macro crate
|
|
|
|
//!
|
|
|
|
//! We separate proc-macro expanding logic to an extern program to allow
|
|
|
|
//! different implementations (e.g. wasm or dylib loading). And this crate
|
2020-04-20 13:26:10 -05:00
|
|
|
//! is used to provide basic infrastructure for communication between two
|
2020-03-25 21:49:23 -05:00
|
|
|
//! processes: Client (RA itself), Server (the external program)
|
2020-03-18 07:56:46 -05:00
|
|
|
|
2022-07-20 07:59:42 -05:00
|
|
|
#![warn(rust_2018_idioms, unused_lifetimes, semicolon_in_expressions_from_macros)]
|
|
|
|
|
2020-03-26 15:26:34 -05:00
|
|
|
pub mod msg;
|
2020-12-11 08:14:42 -06:00
|
|
|
mod process;
|
2021-03-03 20:48:12 -06:00
|
|
|
mod version;
|
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
|
|
|
use paths::AbsPathBuf;
|
2020-12-23 07:24:53 -06:00
|
|
|
use std::{
|
|
|
|
ffi::OsStr,
|
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
|
|
|
fmt, io,
|
2021-07-12 08:19:53 -05:00
|
|
|
sync::{Arc, Mutex},
|
2020-12-23 07:24:53 -06: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
|
|
|
use serde::{Deserialize, Serialize};
|
|
|
|
use tt::Subtree;
|
2020-08-12 09:46:20 -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
|
|
|
use crate::{
|
|
|
|
msg::{ExpandMacro, FlatTree, PanicMessage},
|
|
|
|
process::ProcMacroProcessSrv,
|
2021-08-28 12:36:41 -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
|
|
|
|
2021-03-15 10:38:22 -05:00
|
|
|
pub use version::{read_dylib_info, RustCInfo};
|
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
|
|
|
#[derive(Copy, Clone, Eq, PartialEq, Debug, Serialize, Deserialize)]
|
|
|
|
pub enum ProcMacroKind {
|
|
|
|
CustomDerive,
|
|
|
|
FuncLike,
|
|
|
|
Attr,
|
|
|
|
}
|
|
|
|
|
2021-08-31 07:44:43 -05:00
|
|
|
/// A handle to an external process which load dylibs with macros (.so or .dll)
|
|
|
|
/// and runs actual macro expansion functions.
|
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct ProcMacroServer {
|
|
|
|
/// Currently, the proc macro process expands all procedural macros sequentially.
|
|
|
|
///
|
|
|
|
/// That means that concurrent salsa requests may block each other when expanding proc macros,
|
|
|
|
/// which is unfortunate, but simple and good enough for the time being.
|
|
|
|
///
|
|
|
|
/// Therefore, we just wrap the `ProcMacroProcessSrv` in a mutex here.
|
|
|
|
process: Arc<Mutex<ProcMacroProcessSrv>>,
|
|
|
|
}
|
|
|
|
|
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 struct MacroDylib {
|
|
|
|
path: AbsPathBuf,
|
|
|
|
}
|
|
|
|
|
|
|
|
impl MacroDylib {
|
|
|
|
// FIXME: this is buggy due to TOCTOU, we should check the version in the
|
|
|
|
// macro process instead.
|
|
|
|
pub fn new(path: AbsPathBuf) -> io::Result<MacroDylib> {
|
|
|
|
let _p = profile::span("MacroDylib::new");
|
|
|
|
|
|
|
|
let info = version::read_dylib_info(&path)?;
|
|
|
|
if info.version.0 < 1 || info.version.1 < 47 {
|
|
|
|
let msg = format!("proc-macro {} built by {:#?} is not supported by Rust Analyzer, please update your rust version.", path.display(), info);
|
|
|
|
return Err(io::Error::new(io::ErrorKind::InvalidData, msg));
|
|
|
|
}
|
|
|
|
|
|
|
|
Ok(MacroDylib { path })
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-08-31 07:44:43 -05:00
|
|
|
/// A handle to a specific macro (a `#[proc_macro]` annotated function).
|
|
|
|
///
|
|
|
|
/// It exists withing a context of a specific [`ProcMacroProcess`] -- currently
|
|
|
|
/// we share a single expander process for all macros.
|
2020-03-26 15:26:34 -05:00
|
|
|
#[derive(Debug, Clone)]
|
2021-08-31 07:44:43 -05:00
|
|
|
pub struct ProcMacro {
|
2021-07-12 08:19:53 -05:00
|
|
|
process: Arc<Mutex<ProcMacroProcessSrv>>,
|
2021-07-17 08:54:48 -05:00
|
|
|
dylib_path: AbsPathBuf,
|
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
|
|
|
name: String,
|
2021-08-22 06:05:12 -05:00
|
|
|
kind: ProcMacroKind,
|
2020-03-18 07:56:46 -05:00
|
|
|
}
|
|
|
|
|
2021-08-31 07:44:43 -05:00
|
|
|
impl Eq for ProcMacro {}
|
|
|
|
impl PartialEq for ProcMacro {
|
2020-03-26 15:26:34 -05:00
|
|
|
fn eq(&self, other: &Self) -> bool {
|
|
|
|
self.name == other.name
|
2021-08-22 06:05:12 -05:00
|
|
|
&& self.kind == other.kind
|
2020-03-26 15:26:34 -05:00
|
|
|
&& self.dylib_path == other.dylib_path
|
|
|
|
&& Arc::ptr_eq(&self.process, &other.process)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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 struct ServerError {
|
|
|
|
pub message: String,
|
|
|
|
pub io: Option<io::Error>,
|
|
|
|
}
|
|
|
|
|
|
|
|
impl fmt::Display for ServerError {
|
|
|
|
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
|
2022-03-21 03:43:36 -05:00
|
|
|
self.message.fmt(f)?;
|
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
|
|
|
if let Some(io) = &self.io {
|
2022-03-21 03:43:36 -05:00
|
|
|
f.write_str(": ")?;
|
|
|
|
io.fmt(f)?;
|
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
|
|
|
}
|
|
|
|
Ok(())
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
pub struct MacroPanic {
|
|
|
|
pub message: String,
|
|
|
|
}
|
|
|
|
|
2021-08-31 07:44:43 -05:00
|
|
|
impl ProcMacroServer {
|
2021-07-08 09:40:14 -05:00
|
|
|
/// Spawns an external process as the proc macro server and returns a client connected to it.
|
2021-08-31 07:44:43 -05:00
|
|
|
pub fn spawn(
|
2021-07-17 08:54:48 -05:00
|
|
|
process_path: AbsPathBuf,
|
2020-04-20 13:26:10 -05:00
|
|
|
args: impl IntoIterator<Item = impl AsRef<OsStr>>,
|
2021-08-31 07:44:43 -05:00
|
|
|
) -> io::Result<ProcMacroServer> {
|
2021-07-08 09:40:14 -05:00
|
|
|
let process = ProcMacroProcessSrv::run(process_path, args)?;
|
2021-08-31 07:44:43 -05:00
|
|
|
Ok(ProcMacroServer { process: Arc::new(Mutex::new(process)) })
|
2020-03-18 07:56:46 -05:00
|
|
|
}
|
|
|
|
|
2022-06-15 10:33:55 -05:00
|
|
|
pub fn load_dylib(&self, dylib: MacroDylib) -> Result<Vec<ProcMacro>, ServerError> {
|
2021-04-22 13:25:29 -05:00
|
|
|
let _p = profile::span("ProcMacroClient::by_dylib_path");
|
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 macros =
|
|
|
|
self.process.lock().unwrap_or_else(|e| e.into_inner()).find_proc_macros(&dylib.path)?;
|
|
|
|
|
2022-06-15 10:33:55 -05:00
|
|
|
match macros {
|
|
|
|
Ok(macros) => Ok(macros
|
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
|
|
|
.into_iter()
|
|
|
|
.map(|(name, kind)| ProcMacro {
|
|
|
|
process: self.process.clone(),
|
2021-09-13 11:50:19 -05:00
|
|
|
name,
|
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
|
|
|
kind,
|
|
|
|
dylib_path: dylib.path.clone(),
|
|
|
|
})
|
2022-06-15 10:33:55 -05:00
|
|
|
.collect()),
|
|
|
|
Err(message) => Err(ServerError { message, io: None }),
|
|
|
|
}
|
2020-03-18 04:47:59 -05:00
|
|
|
}
|
|
|
|
}
|
2021-08-31 07:44:43 -05:00
|
|
|
|
|
|
|
impl ProcMacro {
|
|
|
|
pub fn name(&self) -> &str {
|
|
|
|
&self.name
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn kind(&self) -> ProcMacroKind {
|
|
|
|
self.kind
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn expand(
|
|
|
|
&self,
|
|
|
|
subtree: &Subtree,
|
|
|
|
attr: Option<&Subtree>,
|
|
|
|
env: Vec<(String, 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<Result<Subtree, PanicMessage>, ServerError> {
|
2022-01-27 06:54:06 -06:00
|
|
|
let current_dir = env
|
|
|
|
.iter()
|
|
|
|
.find(|(name, _)| name == "CARGO_MANIFEST_DIR")
|
|
|
|
.map(|(_, value)| value.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 task = ExpandMacro {
|
2021-08-31 07:44:43 -05:00
|
|
|
macro_body: FlatTree::new(subtree),
|
|
|
|
macro_name: self.name.to_string(),
|
|
|
|
attributes: attr.map(FlatTree::new),
|
|
|
|
lib: self.dylib_path.to_path_buf().into(),
|
|
|
|
env,
|
2022-01-27 06:54:06 -06:00
|
|
|
current_dir,
|
2021-08-31 07:44:43 -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 request = msg::Request::ExpandMacro(task);
|
|
|
|
let response = self.process.lock().unwrap_or_else(|e| e.into_inner()).send_task(request)?;
|
|
|
|
match response {
|
2021-10-27 07:35:58 -05:00
|
|
|
msg::Response::ExpandMacro(it) => Ok(it.map(FlatTree::to_subtree)),
|
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
|
|
|
msg::Response::ListMacros { .. } => {
|
|
|
|
Err(ServerError { message: "unexpected response".to_string(), io: None })
|
|
|
|
}
|
|
|
|
}
|
2021-08-31 07:44:43 -05:00
|
|
|
}
|
|
|
|
}
|