2020-04-20 13:26:10 -05:00
|
|
|
//! Defines messages for cross-process message passing based on `ndjson` wire protocol
|
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) mod flat;
|
2020-03-26 15:26:34 -05:00
|
|
|
|
|
|
|
use std::{
|
|
|
|
io::{self, BufRead, Write},
|
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
|
|
|
path::PathBuf,
|
2020-03-26 15:26:34 -05:00
|
|
|
};
|
|
|
|
|
2020-08-12 09:46:20 -05:00
|
|
|
use serde::{de::DeserializeOwned, Deserialize, Serialize};
|
|
|
|
|
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::ProcMacroKind;
|
|
|
|
|
|
|
|
pub use crate::msg::flat::FlatTree;
|
2020-03-26 15:26:34 -05:00
|
|
|
|
2021-08-28 12:36:41 -05:00
|
|
|
#[derive(Debug, Serialize, Deserialize)]
|
2020-03-28 05:12:51 -05:00
|
|
|
pub enum Request {
|
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
|
|
|
ListMacros { dylib_path: PathBuf },
|
|
|
|
ExpandMacro(ExpandMacro),
|
2020-03-26 15:26:34 -05:00
|
|
|
}
|
|
|
|
|
2021-08-28 12:36:41 -05:00
|
|
|
#[derive(Debug, Serialize, Deserialize)]
|
2020-03-28 05:12:51 -05:00
|
|
|
pub enum Response {
|
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
|
|
|
ListMacros(Result<Vec<(String, ProcMacroKind)>, String>),
|
|
|
|
ExpandMacro(Result<FlatTree, PanicMessage>),
|
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(Debug, Serialize, Deserialize)]
|
|
|
|
pub struct PanicMessage(pub String);
|
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(Debug, Serialize, Deserialize)]
|
|
|
|
pub struct ExpandMacro {
|
|
|
|
/// Argument of macro call.
|
|
|
|
///
|
|
|
|
/// In custom derive this will be a struct or enum; in attribute-like macro - underlying
|
|
|
|
/// item; in function-like macro - the macro body.
|
|
|
|
pub macro_body: FlatTree,
|
|
|
|
|
|
|
|
/// Name of macro to expand.
|
|
|
|
///
|
|
|
|
/// In custom derive this is the name of the derived trait (`Serialize`, `Getters`, etc.).
|
|
|
|
/// In attribute-like and function-like macros - single name of macro itself (`show_streams`).
|
|
|
|
pub macro_name: String,
|
|
|
|
|
|
|
|
/// Possible attributes for the attribute-like macros.
|
|
|
|
pub attributes: Option<FlatTree>,
|
|
|
|
|
|
|
|
pub lib: PathBuf,
|
|
|
|
|
|
|
|
/// Environment variables to set during macro expansion.
|
|
|
|
pub env: Vec<(String, String)>,
|
2022-01-27 06:54:06 -06:00
|
|
|
|
|
|
|
pub current_dir: Option<String>,
|
2020-03-26 15:26:34 -05:00
|
|
|
}
|
|
|
|
|
2020-04-20 13:26:10 -05:00
|
|
|
pub trait Message: Serialize + DeserializeOwned {
|
2021-03-23 14:47:08 -05:00
|
|
|
fn read(inp: &mut impl BufRead, buf: &mut String) -> io::Result<Option<Self>> {
|
|
|
|
Ok(match read_json(inp, buf)? {
|
2020-04-20 13:26:10 -05:00
|
|
|
None => None,
|
2021-01-01 01:09:27 -06:00
|
|
|
Some(text) => {
|
2021-06-12 22:54:16 -05:00
|
|
|
let mut deserializer = serde_json::Deserializer::from_str(text);
|
2021-01-01 01:09:27 -06:00
|
|
|
// Note that some proc-macro generate very deep syntax tree
|
|
|
|
// We have to disable the current limit of serde here
|
|
|
|
deserializer.disable_recursion_limit();
|
2021-01-01 01:26:55 -06:00
|
|
|
Some(Self::deserialize(&mut deserializer)?)
|
2021-01-01 01:09:27 -06:00
|
|
|
}
|
2020-04-20 13:26:10 -05:00
|
|
|
})
|
2020-03-26 15:26:34 -05:00
|
|
|
}
|
2020-04-20 13:26:10 -05:00
|
|
|
fn write(self, out: &mut impl Write) -> io::Result<()> {
|
2020-03-28 05:12:51 -05:00
|
|
|
let text = serde_json::to_string(&self)?;
|
2020-04-20 13:26:10 -05:00
|
|
|
write_json(out, &text)
|
2020-03-26 15:26:34 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-03-28 05:12:51 -05:00
|
|
|
impl Message for Request {}
|
|
|
|
impl Message for Response {}
|
2020-03-26 15:26:34 -05:00
|
|
|
|
2022-03-12 06:04:13 -06:00
|
|
|
fn read_json<'a>(inp: &mut impl BufRead, buf: &'a mut String) -> io::Result<Option<&'a String>> {
|
2021-03-22 22:22:33 -05:00
|
|
|
loop {
|
2021-03-23 14:47:08 -05:00
|
|
|
buf.clear();
|
|
|
|
|
2022-03-12 06:04:13 -06:00
|
|
|
inp.read_line(buf)?;
|
2021-03-22 22:22:33 -05:00
|
|
|
buf.pop(); // Remove trailing '\n'
|
|
|
|
|
|
|
|
if buf.is_empty() {
|
|
|
|
return Ok(None);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Some ill behaved macro try to use stdout for debugging
|
|
|
|
// We ignore it here
|
2021-06-03 08:32:46 -05:00
|
|
|
if !buf.starts_with('{') {
|
2021-08-15 07:46:13 -05:00
|
|
|
tracing::error!("proc-macro tried to print : {}", buf);
|
2021-03-22 22:22:33 -05:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
return Ok(Some(buf));
|
|
|
|
}
|
2020-03-26 15:26:34 -05:00
|
|
|
}
|
|
|
|
|
2020-03-28 05:12:51 -05:00
|
|
|
fn write_json(out: &mut impl Write, msg: &str) -> io::Result<()> {
|
2021-08-15 07:46:13 -05:00
|
|
|
tracing::debug!("> {}", msg);
|
2020-03-26 15:26:34 -05:00
|
|
|
out.write_all(msg.as_bytes())?;
|
2020-03-28 05:12:51 -05:00
|
|
|
out.write_all(b"\n")?;
|
2020-03-26 15:26:34 -05:00
|
|
|
out.flush()?;
|
|
|
|
Ok(())
|
|
|
|
}
|
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
|
|
|
|
|
|
|
#[cfg(test)]
|
|
|
|
mod tests {
|
|
|
|
use super::*;
|
|
|
|
use tt::*;
|
|
|
|
|
|
|
|
fn fixture_token_tree() -> Subtree {
|
|
|
|
let mut subtree = Subtree::default();
|
|
|
|
subtree
|
|
|
|
.token_trees
|
|
|
|
.push(TokenTree::Leaf(Ident { text: "struct".into(), id: TokenId(0) }.into()));
|
|
|
|
subtree
|
|
|
|
.token_trees
|
|
|
|
.push(TokenTree::Leaf(Ident { text: "Foo".into(), id: TokenId(1) }.into()));
|
|
|
|
subtree.token_trees.push(TokenTree::Leaf(Leaf::Literal(Literal {
|
|
|
|
text: "Foo".into(),
|
|
|
|
id: TokenId::unspecified(),
|
|
|
|
})));
|
|
|
|
subtree.token_trees.push(TokenTree::Leaf(Leaf::Punct(Punct {
|
|
|
|
char: '@',
|
|
|
|
id: TokenId::unspecified(),
|
|
|
|
spacing: Spacing::Joint,
|
|
|
|
})));
|
|
|
|
subtree.token_trees.push(TokenTree::Subtree(Subtree {
|
|
|
|
delimiter: Some(Delimiter { id: TokenId(2), kind: DelimiterKind::Brace }),
|
|
|
|
token_trees: vec![],
|
|
|
|
}));
|
|
|
|
subtree
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn test_proc_macro_rpc_works() {
|
|
|
|
let tt = fixture_token_tree();
|
|
|
|
let task = ExpandMacro {
|
|
|
|
macro_body: FlatTree::new(&tt),
|
|
|
|
macro_name: Default::default(),
|
|
|
|
attributes: None,
|
|
|
|
lib: std::env::current_dir().unwrap(),
|
|
|
|
env: Default::default(),
|
2022-01-27 06:54:06 -06:00
|
|
|
current_dir: Default::default(),
|
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 json = serde_json::to_string(&task).unwrap();
|
|
|
|
// println!("{}", json);
|
|
|
|
let back: ExpandMacro = serde_json::from_str(&json).unwrap();
|
|
|
|
|
|
|
|
assert_eq!(tt, back.macro_body.to_subtree());
|
|
|
|
}
|
|
|
|
}
|