language-servers/rust-analyzer
1
0
Fork 0
mirror of https://github.com/rust-lang/rust-analyzer.git synced 2025-09-28 12:54:58 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 4

internal: remove accidental code re-use

Browse source 
FragmentKind played two roles:

* entry point to the parser
* syntactic category of a macro call

These are different use-cases, and warrant different types. For example,
macro can't expand to visibility, but we have such fragment today.

This PR introduces `ExpandsTo` enum to separate this two use-cases.

I suspect we might further split `FragmentKind` into `$x:specifier` enum
specific to MBE, and a general parser entry point, but that's for
another PR!
This commit is contained in:
Aleksey Kladov 2021-09-05 22:30:06 +03:00
parent 847d0faf92
commit dbb702cfc1
18 changed files with 168 additions and 135 deletions
Download patch file Download diff file Expand all files Collapse all files

8
crates/mbe/src/lib.rs
View file

@ -18,13 +18,15 @@ mod token_map;
use std::fmt;
pub use tt::{Delimiter, DelimiterKind, Punct};
use crate::{
parser::{parse_pattern, parse_template, MetaTemplate, Op},
tt_iter::TtIter,
};
// FIXME: we probably should re-think `token_tree_to_syntax_node` interfaces
pub use ::parser::FragmentKind;
pub use tt::{Delimiter, DelimiterKind, Punct};
#[derive(Debug, PartialEq, Eq)]
pub enum ParseError {
UnexpectedToken(String),
@ -39,7 +41,7 @@ pub enum ExpandError {
UnexpectedToken,
BindingError(String),
ConversionError,
// FXME: no way mbe should know about proc macros.
// FIXME: no way mbe should know about proc macros.
UnresolvedProcMacro,
Other(String),
}