rust-analyzer/crates/mbe/src/syntax_bridge.rs

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

945 lines
31 KiB
Rust
Raw Normal View History

2021-05-22 14:20:22 +00:00
//! Conversions between [`SyntaxNode`] and [`tt::TokenTree`].
use rustc_hash::FxHashMap;
2022-02-07 18:53:31 +00:00
use stdx::{always, non_empty_vec::NonEmptyVec};
2020-08-12 16:26:51 +00:00
use syntax::{
2020-03-08 16:13:04 +00:00
ast::{self, make::tokens::doc_comment},
AstToken, Parse, PreorderWithTokens, SmolStr, SyntaxElement, SyntaxKind,
2020-03-08 16:13:04 +00:00
SyntaxKind::*,
SyntaxNode, SyntaxToken, SyntaxTreeBuilder, TextRange, TextSize, WalkEvent, T,
2019-02-11 18:12:06 +00:00
};
2019-04-07 13:42:53 +00:00
2023-01-31 10:49:49 +00:00
use crate::{
to_parser_input::to_parser_input,
tt::{
self,
buffer::{Cursor, TokenBuffer},
},
tt_iter::TtIter,
TokenMap,
};
2019-11-03 14:46:12 +00:00
2022-11-05 10:01:26 +00:00
#[cfg(test)]
mod tests;
/// Convert the syntax node to a `TokenTree` (what macro
/// will consume).
pub fn syntax_node_to_token_tree(node: &SyntaxNode) -> (tt::Subtree, TokenMap) {
2022-02-09 15:30:10 +00:00
let (subtree, token_map, _) = syntax_node_to_token_tree_with_modifications(
node,
Default::default(),
0,
Default::default(),
Default::default(),
);
(subtree, token_map)
}
/// Convert the syntax node to a `TokenTree` (what macro will consume)
/// with the censored range excluded.
pub fn syntax_node_to_token_tree_with_modifications(
node: &SyntaxNode,
2022-02-09 15:30:10 +00:00
existing_token_map: TokenMap,
next_id: u32,
replace: FxHashMap<SyntaxElement, Vec<SyntheticToken>>,
append: FxHashMap<SyntaxElement, Vec<SyntheticToken>>,
2022-02-09 15:30:10 +00:00
) -> (tt::Subtree, TokenMap, u32) {
2019-11-18 13:08:41 +00:00
let global_offset = node.text_range().start();
2022-11-02 14:26:29 +00:00
let mut c = Converter::new(node, global_offset, existing_token_map, next_id, replace, append);
let subtree = convert_tokens(&mut c);
2021-05-24 16:43:42 +00:00
c.id_alloc.map.shrink_to_fit();
always!(c.replace.is_empty(), "replace: {:?}", c.replace);
always!(c.append.is_empty(), "append: {:?}", c.append);
2022-02-09 15:30:10 +00:00
(subtree, c.id_alloc.map, c.id_alloc.next_id)
}
#[derive(Clone, Copy, Debug, PartialEq, Eq, Hash)]
pub struct SyntheticTokenId(pub u32);
#[derive(Debug, Clone)]
pub struct SyntheticToken {
pub kind: SyntaxKind,
pub text: SmolStr,
pub range: TextRange,
pub id: SyntheticTokenId,
}
// The following items are what `rustc` macro can be parsed into :
// link: https://github.com/rust-lang/rust/blob/9ebf47851a357faa4cd97f4b1dc7835f6376e639/src/libsyntax/ext/expand.rs#L141
2019-04-18 19:49:56 +00:00
// * Expr(P<ast::Expr>) -> token_tree_to_expr
// * Pat(P<ast::Pat>) -> token_tree_to_pat
// * Ty(P<ast::Ty>) -> token_tree_to_ty
// * Stmts(SmallVec<[ast::Stmt; 1]>) -> token_tree_to_stmts
// * Items(SmallVec<[P<ast::Item>; 1]>) -> token_tree_to_items
//
// * TraitItems(SmallVec<[ast::TraitItem; 1]>)
2020-05-05 15:56:10 +00:00
// * AssocItems(SmallVec<[ast::AssocItem; 1]>)
// * ForeignItems(SmallVec<[ast::ForeignItem; 1]>
2019-05-25 13:55:46 +00:00
pub fn token_tree_to_syntax_node(
2019-09-02 15:51:03 +00:00
tt: &tt::Subtree,
2021-12-27 14:54:51 +00:00
entry_point: parser::TopEntryPoint,
2022-01-24 16:27:39 +00:00
) -> (Parse<SyntaxNode>, TokenMap) {
2021-01-04 16:22:42 +00:00
let buffer = match tt {
2023-01-31 10:49:49 +00:00
tt::Subtree {
delimiter: tt::Delimiter { kind: tt::DelimiterKind::Invisible, .. },
token_trees,
} => TokenBuffer::from_tokens(token_trees.as_slice()),
2021-01-04 16:22:42 +00:00
_ => TokenBuffer::from_subtree(tt),
};
2021-12-25 18:59:02 +00:00
let parser_input = to_parser_input(&buffer);
2021-12-27 14:54:51 +00:00
let parser_output = entry_point.parse(&parser_input);
2019-11-03 19:12:19 +00:00
let mut tree_sink = TtTreeSink::new(buffer.begin());
2021-12-25 18:59:02 +00:00
for event in parser_output.iter() {
match event {
2021-12-25 18:59:02 +00:00
parser::Step::Token { kind, n_input_tokens: n_raw_tokens } => {
tree_sink.token(kind, n_raw_tokens)
}
2023-02-07 17:08:05 +00:00
parser::Step::FloatSplit { ends_in_dot: has_pseudo_dot } => {
tree_sink.float_split(has_pseudo_dot)
}
2021-12-25 18:59:02 +00:00
parser::Step::Enter { kind } => tree_sink.start_node(kind),
parser::Step::Exit => tree_sink.finish_node(),
parser::Step::Error { msg } => tree_sink.error(msg.to_string()),
}
}
2023-01-31 10:49:49 +00:00
tree_sink.finish()
2019-09-02 15:51:03 +00:00
}
2020-03-08 16:13:04 +00:00
/// Convert a string to a `TokenTree`
pub fn parse_to_token_tree(text: &str) -> Option<(tt::Subtree, TokenMap)> {
let lexed = parser::LexedStr::new(text);
if lexed.errors().next().is_some() {
2020-03-08 16:13:04 +00:00
return None;
}
2022-11-02 14:26:29 +00:00
let mut conv = RawConverter {
2022-01-02 01:39:14 +00:00
lexed,
pos: 0,
2020-03-08 16:13:04 +00:00
id_alloc: TokenIdAlloc {
map: Default::default(),
2020-04-24 21:40:41 +00:00
global_offset: TextSize::default(),
2020-03-08 16:13:04 +00:00
next_id: 0,
},
};
let subtree = convert_tokens(&mut conv);
2020-03-08 16:13:04 +00:00
Some((subtree, conv.id_alloc.map))
}
/// Split token tree with separate expr: $($e:expr)SEP*
pub fn parse_exprs_with_sep(tt: &tt::Subtree, sep: char) -> Vec<tt::Subtree> {
if tt.token_trees.is_empty() {
return Vec::new();
}
let mut iter = TtIter::new(tt);
let mut res = Vec::new();
while iter.peek_n(0).is_some() {
2021-12-27 13:28:54 +00:00
let expanded = iter.expect_fragment(parser::PrefixEntryPoint::Expr);
res.push(match expanded.value {
None => break,
Some(tt @ tt::TokenTree::Leaf(_)) => {
2023-01-31 10:49:49 +00:00
tt::Subtree { delimiter: tt::Delimiter::unspecified(), token_trees: vec![tt] }
}
Some(tt::TokenTree::Subtree(tt)) => tt,
});
let mut fork = iter.clone();
if fork.expect_char(sep).is_err() {
break;
}
iter = fork;
}
if iter.peek_n(0).is_some() {
2023-01-31 10:49:49 +00:00
res.push(tt::Subtree {
delimiter: tt::Delimiter::unspecified(),
token_trees: iter.cloned().collect(),
});
}
res
}
2022-11-02 14:26:29 +00:00
fn convert_tokens<C: TokenConverter>(conv: &mut C) -> tt::Subtree {
struct StackEntry {
subtree: tt::Subtree,
idx: usize,
open_range: TextRange,
}
let entry = StackEntry {
2023-01-31 10:49:49 +00:00
subtree: tt::Subtree { delimiter: tt::Delimiter::unspecified(), token_trees: vec![] },
// never used (delimiter is `None`)
idx: !0,
open_range: TextRange::empty(TextSize::of('.')),
};
let mut stack = NonEmptyVec::new(entry);
loop {
let StackEntry { subtree, .. } = stack.last_mut();
let result = &mut subtree.token_trees;
let (token, range) = match conv.bump() {
Some(it) => it,
2022-01-02 01:39:14 +00:00
None => break,
};
2022-03-12 12:04:13 +00:00
let synth_id = token.synthetic_id(conv);
2022-03-12 12:04:13 +00:00
let kind = token.kind(conv);
if kind == COMMENT {
// Since `convert_doc_comment` can fail, we need to peek the next id, so that we can
// figure out which token id to use for the doc comment, if it is converted successfully.
let next_id = conv.id_alloc().peek_next_id();
if let Some(tokens) = conv.convert_doc_comment(&token, next_id) {
let id = conv.id_alloc().alloc(range, synth_id);
debug_assert_eq!(id, next_id);
result.extend(tokens);
}
continue;
}
let tt = if kind.is_punct() && kind != UNDERSCORE {
2022-02-09 15:36:06 +00:00
if synth_id.is_none() {
assert_eq!(range.len(), TextSize::of('.'));
}
2023-01-31 10:49:49 +00:00
let expected = match subtree.delimiter.kind {
tt::DelimiterKind::Parenthesis => Some(T![')']),
tt::DelimiterKind::Brace => Some(T!['}']),
tt::DelimiterKind::Bracket => Some(T![']']),
tt::DelimiterKind::Invisible => None,
};
2023-01-31 10:49:49 +00:00
if let Some(expected) = expected {
if kind == expected {
if let Some(entry) = stack.pop() {
conv.id_alloc().close_delim(entry.idx, Some(range));
stack.last_mut().subtree.token_trees.push(entry.subtree.into());
}
continue;
}
}
let delim = match kind {
T!['('] => Some(tt::DelimiterKind::Parenthesis),
T!['{'] => Some(tt::DelimiterKind::Brace),
T!['['] => Some(tt::DelimiterKind::Bracket),
_ => None,
};
if let Some(kind) = delim {
let (id, idx) = conv.id_alloc().open_delim(range, synth_id);
2023-01-31 10:49:49 +00:00
let subtree = tt::Subtree {
delimiter: tt::Delimiter { open: id, close: tt::TokenId::UNSPECIFIED, kind },
token_trees: vec![],
};
stack.push(StackEntry { subtree, idx, open_range: range });
continue;
}
2022-03-12 12:04:13 +00:00
let spacing = match conv.peek().map(|next| next.kind(conv)) {
2022-11-05 10:01:26 +00:00
Some(kind) if is_single_token_op(kind) => tt::Spacing::Joint,
_ => tt::Spacing::Alone,
};
2022-03-12 12:04:13 +00:00
let char = match token.to_char(conv) {
Some(c) => c,
None => {
panic!("Token from lexer must be single char: token = {token:#?}");
}
};
2023-01-31 10:49:49 +00:00
tt::Leaf::from(tt::Punct {
char,
spacing,
span: conv.id_alloc().alloc(range, synth_id),
})
.into()
} else {
macro_rules! make_leaf {
($i:ident) => {
2023-01-31 10:49:49 +00:00
tt::$i {
span: conv.id_alloc().alloc(range, synth_id),
text: token.to_text(conv),
}
.into()
};
}
let leaf: tt::Leaf = match kind {
T![true] | T![false] => make_leaf!(Ident),
IDENT => make_leaf!(Ident),
UNDERSCORE => make_leaf!(Ident),
k if k.is_keyword() => make_leaf!(Ident),
k if k.is_literal() => make_leaf!(Literal),
LIFETIME_IDENT => {
let char_unit = TextSize::of('\'');
let r = TextRange::at(range.start(), char_unit);
let apostrophe = tt::Leaf::from(tt::Punct {
char: '\'',
spacing: tt::Spacing::Joint,
2023-01-31 10:49:49 +00:00
span: conv.id_alloc().alloc(r, synth_id),
});
result.push(apostrophe.into());
let r = TextRange::at(range.start() + char_unit, range.len() - char_unit);
let ident = tt::Leaf::from(tt::Ident {
text: SmolStr::new(&token.to_text(conv)[1..]),
2023-01-31 10:49:49 +00:00
span: conv.id_alloc().alloc(r, synth_id),
});
result.push(ident.into());
continue;
}
_ => continue,
};
leaf.into()
};
result.push(tt);
}
// If we get here, we've consumed all input tokens.
// We might have more than one subtree in the stack, if the delimiters are improperly balanced.
// Merge them so we're left with one.
while let Some(entry) = stack.pop() {
let parent = stack.last_mut();
conv.id_alloc().close_delim(entry.idx, None);
let leaf: tt::Leaf = tt::Punct {
2023-01-31 10:49:49 +00:00
span: conv.id_alloc().alloc(entry.open_range, None),
char: match entry.subtree.delimiter.kind {
tt::DelimiterKind::Parenthesis => '(',
tt::DelimiterKind::Brace => '{',
tt::DelimiterKind::Bracket => '[',
2023-01-31 10:49:49 +00:00
tt::DelimiterKind::Invisible => '$',
},
spacing: tt::Spacing::Alone,
}
.into();
parent.subtree.token_trees.push(leaf.into());
parent.subtree.token_trees.extend(entry.subtree.token_trees);
}
2022-01-02 16:05:37 +00:00
let subtree = stack.into_last().subtree;
if let [tt::TokenTree::Subtree(first)] = &*subtree.token_trees {
first.clone()
} else {
subtree
}
}
2022-11-05 10:01:26 +00:00
fn is_single_token_op(kind: SyntaxKind) -> bool {
matches!(
kind,
EQ | L_ANGLE
| R_ANGLE
| BANG
| AMP
| PIPE
| TILDE
| AT
| DOT
| COMMA
| SEMICOLON
| COLON
| POUND
| DOLLAR
| QUESTION
| PLUS
| MINUS
| STAR
| SLASH
| PERCENT
| CARET
// LIFETIME_IDENT will be split into a sequence of `'` (a single quote) and an
// identifier.
| LIFETIME_IDENT
)
}
2019-05-04 07:00:16 +00:00
/// Returns the textual content of a doc comment block as a quoted string
/// That is, strips leading `///` (or `/**`, etc)
/// and strips the ending `*/`
/// And then quote the string, which is needed to convert to `tt::Literal`
fn doc_comment_text(comment: &ast::Comment) -> SmolStr {
let prefix_len = comment.prefix().len();
let mut text = &comment.text()[prefix_len..];
// Remove ending "*/"
if comment.kind().shape == ast::CommentShape::Block {
text = &text[0..text.len() - 2];
}
// Quote the string
// Note that `tt::Literal` expect an escaped string
let text = format!("\"{}\"", text.escape_debug());
2019-05-04 07:00:16 +00:00
text.into()
}
fn convert_doc_comment(
token: &syntax::SyntaxToken,
span: tt::TokenId,
) -> Option<Vec<tt::TokenTree>> {
2021-10-10 08:39:08 +00:00
cov_mark::hit!(test_meta_doc_comments);
2019-07-18 17:09:50 +00:00
let comment = ast::Comment::cast(token.clone())?;
2019-05-04 07:00:16 +00:00
let doc = comment.kind().doc?;
// Make `doc="\" Comments\""
let meta_tkns =
vec![mk_ident("doc", span), mk_punct('=', span), mk_doc_literal(&comment, span)];
2019-05-04 07:00:16 +00:00
// Make `#![]`
let mut token_trees = Vec::with_capacity(3);
token_trees.push(mk_punct('#', span));
2019-05-04 07:00:16 +00:00
if let ast::CommentPlacement::Inner = doc {
token_trees.push(mk_punct('!', span));
2019-05-04 07:00:16 +00:00
}
2019-06-03 14:21:08 +00:00
token_trees.push(tt::TokenTree::from(tt::Subtree {
delimiter: tt::Delimiter { open: span, close: span, kind: tt::DelimiterKind::Bracket },
2019-06-03 14:21:08 +00:00
token_trees: meta_tkns,
}));
2019-05-04 07:00:16 +00:00
return Some(token_trees);
// Helper functions
fn mk_ident(s: &str, span: tt::TokenId) -> tt::TokenTree {
tt::TokenTree::from(tt::Leaf::from(tt::Ident { text: s.into(), span }))
2019-05-04 07:00:16 +00:00
}
fn mk_punct(c: char, span: tt::TokenId) -> tt::TokenTree {
2019-12-12 13:47:54 +00:00
tt::TokenTree::from(tt::Leaf::from(tt::Punct {
char: c,
spacing: tt::Spacing::Alone,
span,
2019-12-12 13:47:54 +00:00
}))
2019-05-04 07:00:16 +00:00
}
fn mk_doc_literal(comment: &ast::Comment, span: tt::TokenId) -> tt::TokenTree {
let lit = tt::Literal { text: doc_comment_text(comment), span };
2019-05-04 07:00:16 +00:00
tt::TokenTree::from(tt::Leaf::from(lit))
}
}
2020-03-08 16:13:04 +00:00
struct TokenIdAlloc {
2019-11-18 13:08:41 +00:00
map: TokenMap,
2020-04-24 21:40:41 +00:00
global_offset: TextSize,
2019-11-18 13:08:41 +00:00
next_id: u32,
}
2019-04-25 15:12:57 +00:00
2020-03-08 16:13:04 +00:00
impl TokenIdAlloc {
fn alloc(
&mut self,
absolute_range: TextRange,
synthetic_id: Option<SyntheticTokenId>,
) -> tt::TokenId {
2020-03-08 16:13:04 +00:00
let relative_range = absolute_range - self.global_offset;
let token_id = tt::TokenId(self.next_id);
self.next_id += 1;
self.map.insert(token_id, relative_range);
if let Some(id) = synthetic_id {
self.map.insert_synthetic(token_id, id);
}
2020-03-08 16:13:04 +00:00
token_id
}
fn open_delim(
&mut self,
open_abs_range: TextRange,
synthetic_id: Option<SyntheticTokenId>,
) -> (tt::TokenId, usize) {
2020-03-08 16:13:04 +00:00
let token_id = tt::TokenId(self.next_id);
self.next_id += 1;
let idx = self.map.insert_delim(
2020-03-20 20:22:21 +00:00
token_id,
open_abs_range - self.global_offset,
open_abs_range - self.global_offset,
);
if let Some(id) = synthetic_id {
self.map.insert_synthetic(token_id, id);
}
(token_id, idx)
2020-03-08 16:13:04 +00:00
}
fn close_delim(&mut self, idx: usize, close_abs_range: Option<TextRange>) {
2020-03-20 21:20:28 +00:00
match close_abs_range {
None => {
self.map.remove_delim(idx);
2020-03-20 21:20:28 +00:00
}
Some(close) => {
self.map.update_close_delim(idx, close - self.global_offset);
2020-03-20 21:20:28 +00:00
}
}
2020-03-08 16:13:04 +00:00
}
fn peek_next_id(&self) -> tt::TokenId {
tt::TokenId(self.next_id)
}
2020-03-08 16:13:04 +00:00
}
2022-11-02 14:26:29 +00:00
/// A raw token (straight from lexer) converter
struct RawConverter<'a> {
lexed: parser::LexedStr<'a>,
pos: usize,
2020-03-08 16:13:04 +00:00
id_alloc: TokenIdAlloc,
}
trait SrcToken<Ctx>: std::fmt::Debug {
fn kind(&self, ctx: &Ctx) -> SyntaxKind;
2020-03-20 19:04:11 +00:00
fn to_char(&self, ctx: &Ctx) -> Option<char>;
2020-03-20 19:04:11 +00:00
fn to_text(&self, ctx: &Ctx) -> SmolStr;
fn synthetic_id(&self, ctx: &Ctx) -> Option<SyntheticTokenId>;
2020-03-19 12:40:25 +00:00
}
2022-11-02 14:26:29 +00:00
trait TokenConverter: Sized {
type Token: SrcToken<Self>;
2020-03-19 12:40:25 +00:00
fn convert_doc_comment(
&self,
token: &Self::Token,
span: tt::TokenId,
) -> Option<Vec<tt::TokenTree>>;
2020-03-20 19:04:11 +00:00
fn bump(&mut self) -> Option<(Self::Token, TextRange)>;
fn peek(&self) -> Option<Self::Token>;
fn id_alloc(&mut self) -> &mut TokenIdAlloc;
2020-03-19 12:40:25 +00:00
}
2022-11-02 14:26:29 +00:00
impl<'a> SrcToken<RawConverter<'a>> for usize {
fn kind(&self, ctx: &RawConverter<'a>) -> SyntaxKind {
ctx.lexed.kind(*self)
2020-03-08 16:13:04 +00:00
}
2022-11-02 14:26:29 +00:00
fn to_char(&self, ctx: &RawConverter<'a>) -> Option<char> {
ctx.lexed.text(*self).chars().next()
2020-03-08 16:13:04 +00:00
}
2022-11-02 14:26:29 +00:00
fn to_text(&self, ctx: &RawConverter<'_>) -> SmolStr {
ctx.lexed.text(*self).into()
2020-03-08 16:13:04 +00:00
}
2022-11-02 14:26:29 +00:00
fn synthetic_id(&self, _ctx: &RawConverter<'a>) -> Option<SyntheticTokenId> {
None
}
2020-03-20 19:04:11 +00:00
}
2020-03-08 16:13:04 +00:00
2022-11-02 14:26:29 +00:00
impl<'a> TokenConverter for RawConverter<'a> {
type Token = usize;
2020-03-08 16:13:04 +00:00
fn convert_doc_comment(&self, &token: &usize, span: tt::TokenId) -> Option<Vec<tt::TokenTree>> {
let text = self.lexed.text(token);
convert_doc_comment(&doc_comment(text), span)
2020-03-20 19:04:11 +00:00
}
2020-03-08 16:13:04 +00:00
2020-03-20 19:04:11 +00:00
fn bump(&mut self) -> Option<(Self::Token, TextRange)> {
if self.pos == self.lexed.len() {
return None;
}
let token = self.pos;
self.pos += 1;
let range = self.lexed.text_range(token);
let range = TextRange::new(range.start.try_into().unwrap(), range.end.try_into().unwrap());
2020-03-08 16:13:04 +00:00
Some((token, range))
2020-03-20 19:04:11 +00:00
}
2020-03-08 16:13:04 +00:00
2020-03-20 19:04:11 +00:00
fn peek(&self) -> Option<Self::Token> {
if self.pos == self.lexed.len() {
return None;
}
Some(self.pos)
2020-03-20 19:04:11 +00:00
}
fn id_alloc(&mut self) -> &mut TokenIdAlloc {
&mut self.id_alloc
2020-03-08 16:13:04 +00:00
}
}
2022-11-02 14:26:29 +00:00
struct Converter {
2020-03-08 16:13:04 +00:00
id_alloc: TokenIdAlloc,
2020-03-20 19:04:11 +00:00
current: Option<SyntaxToken>,
current_synthetic: Vec<SyntheticToken>,
preorder: PreorderWithTokens,
replace: FxHashMap<SyntaxElement, Vec<SyntheticToken>>,
append: FxHashMap<SyntaxElement, Vec<SyntheticToken>>,
2020-03-20 19:04:11 +00:00
range: TextRange,
2020-04-24 21:40:41 +00:00
punct_offset: Option<(SyntaxToken, TextSize)>,
2020-03-08 16:13:04 +00:00
}
2022-11-02 14:26:29 +00:00
impl Converter {
fn new(
node: &SyntaxNode,
global_offset: TextSize,
2022-02-09 15:30:10 +00:00
existing_token_map: TokenMap,
next_id: u32,
mut replace: FxHashMap<SyntaxElement, Vec<SyntheticToken>>,
mut append: FxHashMap<SyntaxElement, Vec<SyntheticToken>>,
2022-11-02 14:26:29 +00:00
) -> Converter {
let range = node.text_range();
let mut preorder = node.preorder_with_tokens();
2022-02-07 17:17:28 +00:00
let (first, synthetic) = Self::next_token(&mut preorder, &mut replace, &mut append);
2022-11-02 14:26:29 +00:00
Converter {
2022-02-09 15:30:10 +00:00
id_alloc: { TokenIdAlloc { map: existing_token_map, global_offset, next_id } },
current: first,
current_synthetic: synthetic,
preorder,
range,
replace,
append,
2020-03-20 19:04:11 +00:00
punct_offset: None,
2019-11-18 13:08:41 +00:00
}
2020-03-20 19:04:11 +00:00
}
fn next_token(
preorder: &mut PreorderWithTokens,
replace: &mut FxHashMap<SyntaxElement, Vec<SyntheticToken>>,
append: &mut FxHashMap<SyntaxElement, Vec<SyntheticToken>>,
) -> (Option<SyntaxToken>, Vec<SyntheticToken>) {
while let Some(ev) = preorder.next() {
let ele = match ev {
WalkEvent::Enter(ele) => ele,
WalkEvent::Leave(ele) => {
if let Some(mut v) = append.remove(&ele) {
if !v.is_empty() {
2022-02-07 17:17:28 +00:00
v.reverse();
return (None, v);
}
}
continue;
}
};
if let Some(mut v) = replace.remove(&ele) {
preorder.skip_subtree();
if !v.is_empty() {
v.reverse();
return (None, v);
}
}
match ele {
SyntaxElement::Token(t) => return (Some(t), Vec::new()),
_ => {}
}
}
(None, Vec::new())
}
2020-03-20 19:04:11 +00:00
}
2020-04-18 11:28:07 +00:00
#[derive(Debug)]
2020-03-20 19:04:11 +00:00
enum SynToken {
2021-01-08 14:41:46 +00:00
Ordinary(SyntaxToken),
// FIXME is this supposed to be `Punct`?
2020-04-24 21:40:41 +00:00
Punch(SyntaxToken, TextSize),
Synthetic(SyntheticToken),
2020-03-20 19:04:11 +00:00
}
2019-11-21 15:56:01 +00:00
2020-03-20 19:04:11 +00:00
impl SynToken {
fn token(&self) -> Option<&SyntaxToken> {
2020-03-20 19:04:11 +00:00
match self {
SynToken::Ordinary(it) | SynToken::Punch(it, _) => Some(it),
SynToken::Synthetic(_) => None,
2019-11-21 15:56:01 +00:00
}
2020-03-20 19:04:11 +00:00
}
}
2019-11-21 15:56:01 +00:00
2022-11-02 14:26:29 +00:00
impl SrcToken<Converter> for SynToken {
2022-11-05 10:01:26 +00:00
fn kind(&self, ctx: &Converter) -> SyntaxKind {
match self {
SynToken::Ordinary(token) => token.kind(),
2022-11-05 10:01:26 +00:00
SynToken::Punch(..) => SyntaxKind::from_char(self.to_char(ctx).unwrap()).unwrap(),
SynToken::Synthetic(token) => token.kind,
}
2020-03-20 19:04:11 +00:00
}
2022-11-02 14:26:29 +00:00
fn to_char(&self, _ctx: &Converter) -> Option<char> {
2020-03-20 19:04:11 +00:00
match self {
2021-01-08 14:41:46 +00:00
SynToken::Ordinary(_) => None,
2020-04-24 21:40:41 +00:00
SynToken::Punch(it, i) => it.text().chars().nth((*i).into()),
SynToken::Synthetic(token) if token.text.len() == 1 => token.text.chars().next(),
SynToken::Synthetic(_) => None,
2020-03-20 19:04:11 +00:00
}
}
2022-11-02 14:26:29 +00:00
fn to_text(&self, _ctx: &Converter) -> SmolStr {
match self {
SynToken::Ordinary(token) => token.text().into(),
SynToken::Punch(token, _) => token.text().into(),
SynToken::Synthetic(token) => token.text.clone(),
}
}
2022-11-02 14:26:29 +00:00
fn synthetic_id(&self, _ctx: &Converter) -> Option<SyntheticTokenId> {
match self {
SynToken::Synthetic(token) => Some(token.id),
_ => None,
}
2020-03-20 19:04:11 +00:00
}
}
2022-11-02 14:26:29 +00:00
impl TokenConverter for Converter {
2020-03-20 19:04:11 +00:00
type Token = SynToken;
fn convert_doc_comment(
&self,
token: &Self::Token,
span: tt::TokenId,
) -> Option<Vec<tt::TokenTree>> {
convert_doc_comment(token.token()?, span)
2020-03-20 19:04:11 +00:00
}
fn bump(&mut self) -> Option<(Self::Token, TextRange)> {
if let Some((punct, offset)) = self.punct_offset.clone() {
2020-04-24 21:40:41 +00:00
if usize::from(offset) + 1 < punct.text().len() {
2020-04-24 22:57:47 +00:00
let offset = offset + TextSize::of('.');
2020-03-20 19:04:11 +00:00
let range = punct.text_range();
2020-03-20 20:22:21 +00:00
self.punct_offset = Some((punct.clone(), offset));
2020-04-24 21:40:41 +00:00
let range = TextRange::at(range.start() + offset, TextSize::of('.'));
2020-03-20 20:22:21 +00:00
return Some((SynToken::Punch(punct, offset), range));
2019-11-21 15:56:01 +00:00
}
2020-03-20 19:04:11 +00:00
}
if let Some(synth_token) = self.current_synthetic.pop() {
if self.current_synthetic.is_empty() {
let (new_current, new_synth) =
2022-02-07 17:17:28 +00:00
Self::next_token(&mut self.preorder, &mut self.replace, &mut self.append);
self.current = new_current;
self.current_synthetic = new_synth;
}
let range = synth_token.range;
return Some((SynToken::Synthetic(synth_token), range));
}
2020-03-20 20:22:21 +00:00
let curr = self.current.clone()?;
2022-11-05 10:01:26 +00:00
if !self.range.contains_range(curr.text_range()) {
2020-03-20 20:22:21 +00:00
return None;
}
let (new_current, new_synth) =
2022-02-07 17:17:28 +00:00
Self::next_token(&mut self.preorder, &mut self.replace, &mut self.append);
self.current = new_current;
self.current_synthetic = new_synth;
2020-03-20 19:04:11 +00:00
let token = if curr.kind().is_punct() {
self.punct_offset = Some((curr.clone(), 0.into()));
2020-03-20 19:04:11 +00:00
let range = curr.text_range();
2020-04-24 22:57:47 +00:00
let range = TextRange::at(range.start(), TextSize::of('.'));
(SynToken::Punch(curr, 0.into()), range)
2020-03-20 19:04:11 +00:00
} else {
self.punct_offset = None;
let range = curr.text_range();
2021-01-08 14:41:46 +00:00
(SynToken::Ordinary(curr), range)
2019-11-18 13:08:41 +00:00
};
2019-04-24 15:01:32 +00:00
2020-03-20 19:04:11 +00:00
Some(token)
}
2019-05-04 07:00:16 +00:00
2020-03-20 19:04:11 +00:00
fn peek(&self) -> Option<Self::Token> {
if let Some((punct, mut offset)) = self.punct_offset.clone() {
offset += TextSize::of('.');
2020-04-24 21:40:41 +00:00
if usize::from(offset) < punct.text().len() {
2020-03-20 19:04:11 +00:00
return Some(SynToken::Punch(punct, offset));
}
2019-11-18 13:08:41 +00:00
}
if let Some(synth_token) = self.current_synthetic.last() {
return Some(SynToken::Synthetic(synth_token.clone()));
}
2020-03-20 20:22:21 +00:00
let curr = self.current.clone()?;
2020-04-24 21:40:41 +00:00
if !self.range.contains_range(curr.text_range()) {
2020-03-20 20:22:21 +00:00
return None;
}
2020-03-20 19:04:11 +00:00
let token = if curr.kind().is_punct() {
2020-04-24 22:57:47 +00:00
SynToken::Punch(curr, 0.into())
2020-03-20 19:04:11 +00:00
} else {
2021-01-08 14:41:46 +00:00
SynToken::Ordinary(curr)
2020-03-20 19:04:11 +00:00
};
Some(token)
}
fn id_alloc(&mut self) -> &mut TokenIdAlloc {
&mut self.id_alloc
2019-01-31 18:29:04 +00:00
}
}
2019-02-23 11:18:32 +00:00
2019-05-27 14:56:21 +00:00
struct TtTreeSink<'a> {
2019-02-23 14:21:56 +00:00
buf: String,
2019-05-27 14:56:21 +00:00
cursor: Cursor<'a>,
2020-04-24 21:40:41 +00:00
open_delims: FxHashMap<tt::TokenId, TextSize>,
text_pos: TextSize,
2019-02-23 14:21:56 +00:00
inner: SyntaxTreeBuilder,
2019-11-18 13:08:41 +00:00
token_map: TokenMap,
2019-02-23 14:21:56 +00:00
}
2019-05-27 14:56:21 +00:00
impl<'a> TtTreeSink<'a> {
2019-11-03 19:12:19 +00:00
fn new(cursor: Cursor<'a>) -> Self {
2019-02-23 14:21:56 +00:00
TtTreeSink {
buf: String::new(),
2019-05-27 14:56:21 +00:00
cursor,
2019-12-12 17:41:44 +00:00
open_delims: FxHashMap::default(),
2019-02-23 14:21:56 +00:00
text_pos: 0.into(),
inner: SyntaxTreeBuilder::default(),
2019-11-18 13:08:41 +00:00
token_map: TokenMap::default(),
2019-02-23 14:21:56 +00:00
}
}
2019-11-03 19:12:19 +00:00
fn finish(mut self) -> (Parse<SyntaxNode>, TokenMap) {
2021-05-24 16:43:42 +00:00
self.token_map.shrink_to_fit();
2019-11-18 13:08:41 +00:00
(self.inner.finish(), self.token_map)
2019-11-03 19:12:19 +00:00
}
2019-02-23 14:21:56 +00:00
}
2023-01-31 10:49:49 +00:00
fn delim_to_str(d: tt::DelimiterKind, closing: bool) -> Option<&'static str> {
2019-12-18 03:47:26 +00:00
let texts = match d {
internal: replace L_DOLLAR/R_DOLLAR with parenthesis hack The general problem we are dealing with here is this: ``` macro_rules! thrice { ($e:expr) => { $e * 3} } fn main() { let x = thrice!(1 + 2); } ``` we really want this to print 9 rather than 7. The way rustc solves this is rather ad-hoc. In rustc, token trees are allowed to include whole AST fragments, so 1+2 is passed through macro expansion as a single unit. This is a significant violation of token tree model. In rust-analyzer, we intended to handle this in a more elegant way, using token trees with "invisible" delimiters. The idea was is that we introduce a new kind of parenthesis, "left $"/"right $", and let the parser intelligently handle this. The idea was inspired by the relevant comment in the proc_macro crate: https://doc.rust-lang.org/stable/proc_macro/enum.Delimiter.html#variant.None > An implicit delimiter, that may, for example, appear around tokens > coming from a “macro variable” $var. It is important to preserve > operator priorities in cases like $var * 3 where $var is 1 + 2. > Implicit delimiters might not survive roundtrip of a token stream > through a string. Now that we are older and wiser, we conclude that the idea doesn't work. _First_, the comment in the proc-macro crate is wishful thinking. Rustc currently completely ignores none delimiters. It solves the (1 + 2) * 3 problem by having magical token trees which can't be duplicated: * https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/TIL.20that.20token.20streams.20are.20magic * https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Handling.20of.20Delimiter.3A.3ANone.20by.20the.20parser _Second_, it's not like our implementation in rust-analyzer works. We special-case expressions (as opposed to treating all kinds of $var captures the same) and we don't know how parser error recovery should work with these dollar-parenthesis. So, in this PR we simplify the whole thing away by not pretending that we are doing something proper and instead just explicitly special-casing expressions by wrapping them into real `()`. In the future, to maintain bug-parity with `rustc` what we are going to do is probably adding an explicit `CAPTURED_EXPR` *token* which we can explicitly account for in the parser. If/when rustc starts handling delimiter=none properly, we'll port that logic as well, in addition to special handling.
2021-10-23 17:08:42 +00:00
tt::DelimiterKind::Parenthesis => "()",
tt::DelimiterKind::Brace => "{}",
tt::DelimiterKind::Bracket => "[]",
2023-01-31 10:49:49 +00:00
tt::DelimiterKind::Invisible => return None,
2019-05-27 14:56:21 +00:00
};
let idx = closing as usize;
2023-01-31 10:49:49 +00:00
Some(&texts[idx..texts.len() - (1 - idx)])
}
impl<'a> TtTreeSink<'a> {
2023-02-07 17:08:05 +00:00
/// Parses a float literal as if it was a one to two name ref nodes with a dot inbetween.
/// This occurs when a float literal is used as a field access.
fn float_split(&mut self, has_pseudo_dot: bool) {
let (text, _span) = match self.cursor.token_tree() {
Some(tt::buffer::TokenTreeRef::Leaf(tt::Leaf::Literal(lit), _)) => {
(lit.text.as_str(), lit.span)
}
_ => unreachable!(),
};
match text.split_once('.') {
Some((left, right)) => {
assert!(!left.is_empty());
self.inner.start_node(SyntaxKind::NAME_REF);
self.inner.token(SyntaxKind::INT_NUMBER, left);
self.inner.finish_node();
// here we move the exit up, the original exit has been deleted in process
self.inner.finish_node();
self.inner.token(SyntaxKind::DOT, ".");
if has_pseudo_dot {
assert!(right.is_empty(), "{left}.{right}");
} else {
self.inner.start_node(SyntaxKind::NAME_REF);
self.inner.token(SyntaxKind::INT_NUMBER, right);
self.inner.finish_node();
// the parser creates an unbalanced start node, we are required to close it here
self.inner.finish_node();
}
}
None => unreachable!(),
}
self.cursor = self.cursor.bump();
}
2020-04-18 11:28:07 +00:00
fn token(&mut self, kind: SyntaxKind, mut n_tokens: u8) {
2020-12-15 18:23:51 +00:00
if kind == LIFETIME_IDENT {
2020-04-18 11:28:07 +00:00
n_tokens = 2;
}
2020-03-04 15:38:58 +00:00
let mut last = self.cursor;
2019-02-23 14:21:56 +00:00
for _ in 0..n_tokens {
2022-01-02 11:40:46 +00:00
let tmp: u8;
2019-05-27 14:56:21 +00:00
if self.cursor.eof() {
break;
}
2020-03-04 15:38:58 +00:00
last = self.cursor;
internal: replace L_DOLLAR/R_DOLLAR with parenthesis hack The general problem we are dealing with here is this: ``` macro_rules! thrice { ($e:expr) => { $e * 3} } fn main() { let x = thrice!(1 + 2); } ``` we really want this to print 9 rather than 7. The way rustc solves this is rather ad-hoc. In rustc, token trees are allowed to include whole AST fragments, so 1+2 is passed through macro expansion as a single unit. This is a significant violation of token tree model. In rust-analyzer, we intended to handle this in a more elegant way, using token trees with "invisible" delimiters. The idea was is that we introduce a new kind of parenthesis, "left $"/"right $", and let the parser intelligently handle this. The idea was inspired by the relevant comment in the proc_macro crate: https://doc.rust-lang.org/stable/proc_macro/enum.Delimiter.html#variant.None > An implicit delimiter, that may, for example, appear around tokens > coming from a “macro variable” $var. It is important to preserve > operator priorities in cases like $var * 3 where $var is 1 + 2. > Implicit delimiters might not survive roundtrip of a token stream > through a string. Now that we are older and wiser, we conclude that the idea doesn't work. _First_, the comment in the proc-macro crate is wishful thinking. Rustc currently completely ignores none delimiters. It solves the (1 + 2) * 3 problem by having magical token trees which can't be duplicated: * https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/TIL.20that.20token.20streams.20are.20magic * https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Handling.20of.20Delimiter.3A.3ANone.20by.20the.20parser _Second_, it's not like our implementation in rust-analyzer works. We special-case expressions (as opposed to treating all kinds of $var captures the same) and we don't know how parser error recovery should work with these dollar-parenthesis. So, in this PR we simplify the whole thing away by not pretending that we are doing something proper and instead just explicitly special-casing expressions by wrapping them into real `()`. In the future, to maintain bug-parity with `rustc` what we are going to do is probably adding an explicit `CAPTURED_EXPR` *token* which we can explicitly account for in the parser. If/when rustc starts handling delimiter=none properly, we'll port that logic as well, in addition to special handling.
2021-10-23 17:08:42 +00:00
let text: &str = loop {
break match self.cursor.token_tree() {
Some(tt::buffer::TokenTreeRef::Leaf(leaf, _)) => {
// Mark the range if needed
let (text, id) = match leaf {
2023-01-31 10:49:49 +00:00
tt::Leaf::Ident(ident) => (ident.text.as_str(), ident.span),
internal: replace L_DOLLAR/R_DOLLAR with parenthesis hack The general problem we are dealing with here is this: ``` macro_rules! thrice { ($e:expr) => { $e * 3} } fn main() { let x = thrice!(1 + 2); } ``` we really want this to print 9 rather than 7. The way rustc solves this is rather ad-hoc. In rustc, token trees are allowed to include whole AST fragments, so 1+2 is passed through macro expansion as a single unit. This is a significant violation of token tree model. In rust-analyzer, we intended to handle this in a more elegant way, using token trees with "invisible" delimiters. The idea was is that we introduce a new kind of parenthesis, "left $"/"right $", and let the parser intelligently handle this. The idea was inspired by the relevant comment in the proc_macro crate: https://doc.rust-lang.org/stable/proc_macro/enum.Delimiter.html#variant.None > An implicit delimiter, that may, for example, appear around tokens > coming from a “macro variable” $var. It is important to preserve > operator priorities in cases like $var * 3 where $var is 1 + 2. > Implicit delimiters might not survive roundtrip of a token stream > through a string. Now that we are older and wiser, we conclude that the idea doesn't work. _First_, the comment in the proc-macro crate is wishful thinking. Rustc currently completely ignores none delimiters. It solves the (1 + 2) * 3 problem by having magical token trees which can't be duplicated: * https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/TIL.20that.20token.20streams.20are.20magic * https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Handling.20of.20Delimiter.3A.3ANone.20by.20the.20parser _Second_, it's not like our implementation in rust-analyzer works. We special-case expressions (as opposed to treating all kinds of $var captures the same) and we don't know how parser error recovery should work with these dollar-parenthesis. So, in this PR we simplify the whole thing away by not pretending that we are doing something proper and instead just explicitly special-casing expressions by wrapping them into real `()`. In the future, to maintain bug-parity with `rustc` what we are going to do is probably adding an explicit `CAPTURED_EXPR` *token* which we can explicitly account for in the parser. If/when rustc starts handling delimiter=none properly, we'll port that logic as well, in addition to special handling.
2021-10-23 17:08:42 +00:00
tt::Leaf::Punct(punct) => {
assert!(punct.char.is_ascii());
2022-01-02 11:40:46 +00:00
tmp = punct.char as u8;
2023-01-31 10:49:49 +00:00
(
std::str::from_utf8(std::slice::from_ref(&tmp)).unwrap(),
punct.span,
)
internal: replace L_DOLLAR/R_DOLLAR with parenthesis hack The general problem we are dealing with here is this: ``` macro_rules! thrice { ($e:expr) => { $e * 3} } fn main() { let x = thrice!(1 + 2); } ``` we really want this to print 9 rather than 7. The way rustc solves this is rather ad-hoc. In rustc, token trees are allowed to include whole AST fragments, so 1+2 is passed through macro expansion as a single unit. This is a significant violation of token tree model. In rust-analyzer, we intended to handle this in a more elegant way, using token trees with "invisible" delimiters. The idea was is that we introduce a new kind of parenthesis, "left $"/"right $", and let the parser intelligently handle this. The idea was inspired by the relevant comment in the proc_macro crate: https://doc.rust-lang.org/stable/proc_macro/enum.Delimiter.html#variant.None > An implicit delimiter, that may, for example, appear around tokens > coming from a “macro variable” $var. It is important to preserve > operator priorities in cases like $var * 3 where $var is 1 + 2. > Implicit delimiters might not survive roundtrip of a token stream > through a string. Now that we are older and wiser, we conclude that the idea doesn't work. _First_, the comment in the proc-macro crate is wishful thinking. Rustc currently completely ignores none delimiters. It solves the (1 + 2) * 3 problem by having magical token trees which can't be duplicated: * https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/TIL.20that.20token.20streams.20are.20magic * https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Handling.20of.20Delimiter.3A.3ANone.20by.20the.20parser _Second_, it's not like our implementation in rust-analyzer works. We special-case expressions (as opposed to treating all kinds of $var captures the same) and we don't know how parser error recovery should work with these dollar-parenthesis. So, in this PR we simplify the whole thing away by not pretending that we are doing something proper and instead just explicitly special-casing expressions by wrapping them into real `()`. In the future, to maintain bug-parity with `rustc` what we are going to do is probably adding an explicit `CAPTURED_EXPR` *token* which we can explicitly account for in the parser. If/when rustc starts handling delimiter=none properly, we'll port that logic as well, in addition to special handling.
2021-10-23 17:08:42 +00:00
}
2023-01-31 10:49:49 +00:00
tt::Leaf::Literal(lit) => (lit.text.as_str(), lit.span),
internal: replace L_DOLLAR/R_DOLLAR with parenthesis hack The general problem we are dealing with here is this: ``` macro_rules! thrice { ($e:expr) => { $e * 3} } fn main() { let x = thrice!(1 + 2); } ``` we really want this to print 9 rather than 7. The way rustc solves this is rather ad-hoc. In rustc, token trees are allowed to include whole AST fragments, so 1+2 is passed through macro expansion as a single unit. This is a significant violation of token tree model. In rust-analyzer, we intended to handle this in a more elegant way, using token trees with "invisible" delimiters. The idea was is that we introduce a new kind of parenthesis, "left $"/"right $", and let the parser intelligently handle this. The idea was inspired by the relevant comment in the proc_macro crate: https://doc.rust-lang.org/stable/proc_macro/enum.Delimiter.html#variant.None > An implicit delimiter, that may, for example, appear around tokens > coming from a “macro variable” $var. It is important to preserve > operator priorities in cases like $var * 3 where $var is 1 + 2. > Implicit delimiters might not survive roundtrip of a token stream > through a string. Now that we are older and wiser, we conclude that the idea doesn't work. _First_, the comment in the proc-macro crate is wishful thinking. Rustc currently completely ignores none delimiters. It solves the (1 + 2) * 3 problem by having magical token trees which can't be duplicated: * https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/TIL.20that.20token.20streams.20are.20magic * https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Handling.20of.20Delimiter.3A.3ANone.20by.20the.20parser _Second_, it's not like our implementation in rust-analyzer works. We special-case expressions (as opposed to treating all kinds of $var captures the same) and we don't know how parser error recovery should work with these dollar-parenthesis. So, in this PR we simplify the whole thing away by not pretending that we are doing something proper and instead just explicitly special-casing expressions by wrapping them into real `()`. In the future, to maintain bug-parity with `rustc` what we are going to do is probably adding an explicit `CAPTURED_EXPR` *token* which we can explicitly account for in the parser. If/when rustc starts handling delimiter=none properly, we'll port that logic as well, in addition to special handling.
2021-10-23 17:08:42 +00:00
};
2022-01-02 11:40:46 +00:00
let range = TextRange::at(self.text_pos, TextSize::of(text));
internal: replace L_DOLLAR/R_DOLLAR with parenthesis hack The general problem we are dealing with here is this: ``` macro_rules! thrice { ($e:expr) => { $e * 3} } fn main() { let x = thrice!(1 + 2); } ``` we really want this to print 9 rather than 7. The way rustc solves this is rather ad-hoc. In rustc, token trees are allowed to include whole AST fragments, so 1+2 is passed through macro expansion as a single unit. This is a significant violation of token tree model. In rust-analyzer, we intended to handle this in a more elegant way, using token trees with "invisible" delimiters. The idea was is that we introduce a new kind of parenthesis, "left $"/"right $", and let the parser intelligently handle this. The idea was inspired by the relevant comment in the proc_macro crate: https://doc.rust-lang.org/stable/proc_macro/enum.Delimiter.html#variant.None > An implicit delimiter, that may, for example, appear around tokens > coming from a “macro variable” $var. It is important to preserve > operator priorities in cases like $var * 3 where $var is 1 + 2. > Implicit delimiters might not survive roundtrip of a token stream > through a string. Now that we are older and wiser, we conclude that the idea doesn't work. _First_, the comment in the proc-macro crate is wishful thinking. Rustc currently completely ignores none delimiters. It solves the (1 + 2) * 3 problem by having magical token trees which can't be duplicated: * https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/TIL.20that.20token.20streams.20are.20magic * https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Handling.20of.20Delimiter.3A.3ANone.20by.20the.20parser _Second_, it's not like our implementation in rust-analyzer works. We special-case expressions (as opposed to treating all kinds of $var captures the same) and we don't know how parser error recovery should work with these dollar-parenthesis. So, in this PR we simplify the whole thing away by not pretending that we are doing something proper and instead just explicitly special-casing expressions by wrapping them into real `()`. In the future, to maintain bug-parity with `rustc` what we are going to do is probably adding an explicit `CAPTURED_EXPR` *token* which we can explicitly account for in the parser. If/when rustc starts handling delimiter=none properly, we'll port that logic as well, in addition to special handling.
2021-10-23 17:08:42 +00:00
self.token_map.insert(id, range);
self.cursor = self.cursor.bump();
text
}
Some(tt::buffer::TokenTreeRef::Subtree(subtree, _)) => {
self.cursor = self.cursor.subtree().unwrap();
2023-01-31 10:49:49 +00:00
match delim_to_str(subtree.delimiter.kind, false) {
Some(it) => {
self.open_delims.insert(subtree.delimiter.open, self.text_pos);
it
internal: replace L_DOLLAR/R_DOLLAR with parenthesis hack The general problem we are dealing with here is this: ``` macro_rules! thrice { ($e:expr) => { $e * 3} } fn main() { let x = thrice!(1 + 2); } ``` we really want this to print 9 rather than 7. The way rustc solves this is rather ad-hoc. In rustc, token trees are allowed to include whole AST fragments, so 1+2 is passed through macro expansion as a single unit. This is a significant violation of token tree model. In rust-analyzer, we intended to handle this in a more elegant way, using token trees with "invisible" delimiters. The idea was is that we introduce a new kind of parenthesis, "left $"/"right $", and let the parser intelligently handle this. The idea was inspired by the relevant comment in the proc_macro crate: https://doc.rust-lang.org/stable/proc_macro/enum.Delimiter.html#variant.None > An implicit delimiter, that may, for example, appear around tokens > coming from a “macro variable” $var. It is important to preserve > operator priorities in cases like $var * 3 where $var is 1 + 2. > Implicit delimiters might not survive roundtrip of a token stream > through a string. Now that we are older and wiser, we conclude that the idea doesn't work. _First_, the comment in the proc-macro crate is wishful thinking. Rustc currently completely ignores none delimiters. It solves the (1 + 2) * 3 problem by having magical token trees which can't be duplicated: * https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/TIL.20that.20token.20streams.20are.20magic * https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Handling.20of.20Delimiter.3A.3ANone.20by.20the.20parser _Second_, it's not like our implementation in rust-analyzer works. We special-case expressions (as opposed to treating all kinds of $var captures the same) and we don't know how parser error recovery should work with these dollar-parenthesis. So, in this PR we simplify the whole thing away by not pretending that we are doing something proper and instead just explicitly special-casing expressions by wrapping them into real `()`. In the future, to maintain bug-parity with `rustc` what we are going to do is probably adding an explicit `CAPTURED_EXPR` *token* which we can explicitly account for in the parser. If/when rustc starts handling delimiter=none properly, we'll port that logic as well, in addition to special handling.
2021-10-23 17:08:42 +00:00
}
None => continue,
}
2019-05-27 14:56:21 +00:00
}
internal: replace L_DOLLAR/R_DOLLAR with parenthesis hack The general problem we are dealing with here is this: ``` macro_rules! thrice { ($e:expr) => { $e * 3} } fn main() { let x = thrice!(1 + 2); } ``` we really want this to print 9 rather than 7. The way rustc solves this is rather ad-hoc. In rustc, token trees are allowed to include whole AST fragments, so 1+2 is passed through macro expansion as a single unit. This is a significant violation of token tree model. In rust-analyzer, we intended to handle this in a more elegant way, using token trees with "invisible" delimiters. The idea was is that we introduce a new kind of parenthesis, "left $"/"right $", and let the parser intelligently handle this. The idea was inspired by the relevant comment in the proc_macro crate: https://doc.rust-lang.org/stable/proc_macro/enum.Delimiter.html#variant.None > An implicit delimiter, that may, for example, appear around tokens > coming from a “macro variable” $var. It is important to preserve > operator priorities in cases like $var * 3 where $var is 1 + 2. > Implicit delimiters might not survive roundtrip of a token stream > through a string. Now that we are older and wiser, we conclude that the idea doesn't work. _First_, the comment in the proc-macro crate is wishful thinking. Rustc currently completely ignores none delimiters. It solves the (1 + 2) * 3 problem by having magical token trees which can't be duplicated: * https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/TIL.20that.20token.20streams.20are.20magic * https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Handling.20of.20Delimiter.3A.3ANone.20by.20the.20parser _Second_, it's not like our implementation in rust-analyzer works. We special-case expressions (as opposed to treating all kinds of $var captures the same) and we don't know how parser error recovery should work with these dollar-parenthesis. So, in this PR we simplify the whole thing away by not pretending that we are doing something proper and instead just explicitly special-casing expressions by wrapping them into real `()`. In the future, to maintain bug-parity with `rustc` what we are going to do is probably adding an explicit `CAPTURED_EXPR` *token* which we can explicitly account for in the parser. If/when rustc starts handling delimiter=none properly, we'll port that logic as well, in addition to special handling.
2021-10-23 17:08:42 +00:00
None => {
let parent = self.cursor.end().unwrap();
2019-12-18 03:47:26 +00:00
self.cursor = self.cursor.bump();
2023-01-31 10:49:49 +00:00
match delim_to_str(parent.delimiter.kind, true) {
Some(it) => {
if let Some(open_delim) =
self.open_delims.get(&parent.delimiter.open)
{
internal: replace L_DOLLAR/R_DOLLAR with parenthesis hack The general problem we are dealing with here is this: ``` macro_rules! thrice { ($e:expr) => { $e * 3} } fn main() { let x = thrice!(1 + 2); } ``` we really want this to print 9 rather than 7. The way rustc solves this is rather ad-hoc. In rustc, token trees are allowed to include whole AST fragments, so 1+2 is passed through macro expansion as a single unit. This is a significant violation of token tree model. In rust-analyzer, we intended to handle this in a more elegant way, using token trees with "invisible" delimiters. The idea was is that we introduce a new kind of parenthesis, "left $"/"right $", and let the parser intelligently handle this. The idea was inspired by the relevant comment in the proc_macro crate: https://doc.rust-lang.org/stable/proc_macro/enum.Delimiter.html#variant.None > An implicit delimiter, that may, for example, appear around tokens > coming from a “macro variable” $var. It is important to preserve > operator priorities in cases like $var * 3 where $var is 1 + 2. > Implicit delimiters might not survive roundtrip of a token stream > through a string. Now that we are older and wiser, we conclude that the idea doesn't work. _First_, the comment in the proc-macro crate is wishful thinking. Rustc currently completely ignores none delimiters. It solves the (1 + 2) * 3 problem by having magical token trees which can't be duplicated: * https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/TIL.20that.20token.20streams.20are.20magic * https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Handling.20of.20Delimiter.3A.3ANone.20by.20the.20parser _Second_, it's not like our implementation in rust-analyzer works. We special-case expressions (as opposed to treating all kinds of $var captures the same) and we don't know how parser error recovery should work with these dollar-parenthesis. So, in this PR we simplify the whole thing away by not pretending that we are doing something proper and instead just explicitly special-casing expressions by wrapping them into real `()`. In the future, to maintain bug-parity with `rustc` what we are going to do is probably adding an explicit `CAPTURED_EXPR` *token* which we can explicitly account for in the parser. If/when rustc starts handling delimiter=none properly, we'll port that logic as well, in addition to special handling.
2021-10-23 17:08:42 +00:00
let open_range = TextRange::at(*open_delim, TextSize::of('('));
let close_range =
TextRange::at(self.text_pos, TextSize::of('('));
2023-01-31 10:49:49 +00:00
self.token_map.insert_delim(
parent.delimiter.open,
open_range,
close_range,
);
internal: replace L_DOLLAR/R_DOLLAR with parenthesis hack The general problem we are dealing with here is this: ``` macro_rules! thrice { ($e:expr) => { $e * 3} } fn main() { let x = thrice!(1 + 2); } ``` we really want this to print 9 rather than 7. The way rustc solves this is rather ad-hoc. In rustc, token trees are allowed to include whole AST fragments, so 1+2 is passed through macro expansion as a single unit. This is a significant violation of token tree model. In rust-analyzer, we intended to handle this in a more elegant way, using token trees with "invisible" delimiters. The idea was is that we introduce a new kind of parenthesis, "left $"/"right $", and let the parser intelligently handle this. The idea was inspired by the relevant comment in the proc_macro crate: https://doc.rust-lang.org/stable/proc_macro/enum.Delimiter.html#variant.None > An implicit delimiter, that may, for example, appear around tokens > coming from a “macro variable” $var. It is important to preserve > operator priorities in cases like $var * 3 where $var is 1 + 2. > Implicit delimiters might not survive roundtrip of a token stream > through a string. Now that we are older and wiser, we conclude that the idea doesn't work. _First_, the comment in the proc-macro crate is wishful thinking. Rustc currently completely ignores none delimiters. It solves the (1 + 2) * 3 problem by having magical token trees which can't be duplicated: * https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/TIL.20that.20token.20streams.20are.20magic * https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Handling.20of.20Delimiter.3A.3ANone.20by.20the.20parser _Second_, it's not like our implementation in rust-analyzer works. We special-case expressions (as opposed to treating all kinds of $var captures the same) and we don't know how parser error recovery should work with these dollar-parenthesis. So, in this PR we simplify the whole thing away by not pretending that we are doing something proper and instead just explicitly special-casing expressions by wrapping them into real `()`. In the future, to maintain bug-parity with `rustc` what we are going to do is probably adding an explicit `CAPTURED_EXPR` *token* which we can explicitly account for in the parser. If/when rustc starts handling delimiter=none properly, we'll port that logic as well, in addition to special handling.
2021-10-23 17:08:42 +00:00
}
2023-01-31 10:49:49 +00:00
it
2019-12-18 03:47:26 +00:00
}
internal: replace L_DOLLAR/R_DOLLAR with parenthesis hack The general problem we are dealing with here is this: ``` macro_rules! thrice { ($e:expr) => { $e * 3} } fn main() { let x = thrice!(1 + 2); } ``` we really want this to print 9 rather than 7. The way rustc solves this is rather ad-hoc. In rustc, token trees are allowed to include whole AST fragments, so 1+2 is passed through macro expansion as a single unit. This is a significant violation of token tree model. In rust-analyzer, we intended to handle this in a more elegant way, using token trees with "invisible" delimiters. The idea was is that we introduce a new kind of parenthesis, "left $"/"right $", and let the parser intelligently handle this. The idea was inspired by the relevant comment in the proc_macro crate: https://doc.rust-lang.org/stable/proc_macro/enum.Delimiter.html#variant.None > An implicit delimiter, that may, for example, appear around tokens > coming from a “macro variable” $var. It is important to preserve > operator priorities in cases like $var * 3 where $var is 1 + 2. > Implicit delimiters might not survive roundtrip of a token stream > through a string. Now that we are older and wiser, we conclude that the idea doesn't work. _First_, the comment in the proc-macro crate is wishful thinking. Rustc currently completely ignores none delimiters. It solves the (1 + 2) * 3 problem by having magical token trees which can't be duplicated: * https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/TIL.20that.20token.20streams.20are.20magic * https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Handling.20of.20Delimiter.3A.3ANone.20by.20the.20parser _Second_, it's not like our implementation in rust-analyzer works. We special-case expressions (as opposed to treating all kinds of $var captures the same) and we don't know how parser error recovery should work with these dollar-parenthesis. So, in this PR we simplify the whole thing away by not pretending that we are doing something proper and instead just explicitly special-casing expressions by wrapping them into real `()`. In the future, to maintain bug-parity with `rustc` what we are going to do is probably adding an explicit `CAPTURED_EXPR` *token* which we can explicitly account for in the parser. If/when rustc starts handling delimiter=none properly, we'll port that logic as well, in addition to special handling.
2021-10-23 17:08:42 +00:00
None => continue,
2019-12-12 17:41:44 +00:00
}
}
internal: replace L_DOLLAR/R_DOLLAR with parenthesis hack The general problem we are dealing with here is this: ``` macro_rules! thrice { ($e:expr) => { $e * 3} } fn main() { let x = thrice!(1 + 2); } ``` we really want this to print 9 rather than 7. The way rustc solves this is rather ad-hoc. In rustc, token trees are allowed to include whole AST fragments, so 1+2 is passed through macro expansion as a single unit. This is a significant violation of token tree model. In rust-analyzer, we intended to handle this in a more elegant way, using token trees with "invisible" delimiters. The idea was is that we introduce a new kind of parenthesis, "left $"/"right $", and let the parser intelligently handle this. The idea was inspired by the relevant comment in the proc_macro crate: https://doc.rust-lang.org/stable/proc_macro/enum.Delimiter.html#variant.None > An implicit delimiter, that may, for example, appear around tokens > coming from a “macro variable” $var. It is important to preserve > operator priorities in cases like $var * 3 where $var is 1 + 2. > Implicit delimiters might not survive roundtrip of a token stream > through a string. Now that we are older and wiser, we conclude that the idea doesn't work. _First_, the comment in the proc-macro crate is wishful thinking. Rustc currently completely ignores none delimiters. It solves the (1 + 2) * 3 problem by having magical token trees which can't be duplicated: * https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/TIL.20that.20token.20streams.20are.20magic * https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Handling.20of.20Delimiter.3A.3ANone.20by.20the.20parser _Second_, it's not like our implementation in rust-analyzer works. We special-case expressions (as opposed to treating all kinds of $var captures the same) and we don't know how parser error recovery should work with these dollar-parenthesis. So, in this PR we simplify the whole thing away by not pretending that we are doing something proper and instead just explicitly special-casing expressions by wrapping them into real `()`. In the future, to maintain bug-parity with `rustc` what we are going to do is probably adding an explicit `CAPTURED_EXPR` *token* which we can explicitly account for in the parser. If/when rustc starts handling delimiter=none properly, we'll port that logic as well, in addition to special handling.
2021-10-23 17:08:42 +00:00
};
2019-05-27 14:56:21 +00:00
};
2021-06-13 03:54:16 +00:00
self.buf += text;
2021-01-04 16:11:56 +00:00
self.text_pos += TextSize::of(text);
2019-02-23 14:21:56 +00:00
}
2019-05-27 14:56:21 +00:00
self.inner.token(kind, self.buf.as_str());
2019-02-23 14:21:56 +00:00
self.buf.clear();
2019-05-27 14:56:21 +00:00
// Add whitespace between adjoint puncts
2020-03-04 15:38:58 +00:00
let next = last.bump();
2019-05-27 14:56:21 +00:00
if let (
2021-01-04 16:22:42 +00:00
Some(tt::buffer::TokenTreeRef::Leaf(tt::Leaf::Punct(curr), _)),
2022-11-05 10:01:26 +00:00
Some(tt::buffer::TokenTreeRef::Leaf(tt::Leaf::Punct(next), _)),
2020-03-04 15:38:58 +00:00
) = (last.token_tree(), next.token_tree())
2019-05-27 14:56:21 +00:00
{
2020-03-05 20:32:08 +00:00
// Note: We always assume the semi-colon would be the last token in
// other parts of RA such that we don't add whitespace here.
2022-11-05 10:01:26 +00:00
//
// When `next` is a `Punct` of `'`, that's a part of a lifetime identifier so we don't
// need to add whitespace either.
if curr.spacing == tt::Spacing::Alone && curr.char != ';' && next.char != '\'' {
self.inner.token(WHITESPACE, " ");
2020-04-24 21:40:41 +00:00
self.text_pos += TextSize::of(' ');
}
}
2019-02-23 14:21:56 +00:00
}
2019-03-30 10:25:53 +00:00
fn start_node(&mut self, kind: SyntaxKind) {
self.inner.start_node(kind);
2019-02-23 14:21:56 +00:00
}
2019-03-30 10:25:53 +00:00
fn finish_node(&mut self) {
self.inner.finish_node();
2019-02-23 14:21:56 +00:00
}
fn error(&mut self, error: String) {
2019-02-23 14:21:56 +00:00
self.inner.error(error, self.text_pos)
}
}