-
-
Notifications
You must be signed in to change notification settings - Fork 262
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add to support include!
for load partial for Pest grammars.
#759
Conversation
Or how about use: A. Import
B. Require same as Node.js, Ruby
C. Rust
|
9ba7839
to
6f5ee1b
Compare
@CAD97 I have updated syntax to |
26cf4ed
to
58af2e9
Compare
use
for load partial for Pest grammars.include!
for load partial for Pest grammars.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I merged that original split PR, so this can be rebased on top of the latest master
base.pest ```pest WHITESPACE = _{ " " | "\t" | "\r" | "\n" } ``` json.pest ```pest use "base.pest" json = { ... } ``` Will same as: ```pest WHITESPACE = _{ " " | "\t" | "\r" | "\n" } json = { ... } ```
58af2e9
to
8b454ec
Compare
@tomtau I have updated |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems all right. I don't have any special preference for the syntax: include may be fine, just that Rust-like syntax form may perhaps be confusing to lead people into thinking they can embed Rust code.
One thing that's missing is docs: when should one use this include statement versus using multiple derive expressions?
@huacnlee from those docs, if I understand it correctly, |
By my mind, Because of this is same as the Rust In most sense, we just need focus on the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm putting this one on hold for now, because it's not obvious what specific problem it solves (given multiple grammar file loading is already supported via derive generators #758) and whether it's worth extending the meta grammar with a feature that duplicates what is already possible using derive generators.
If someone from @pest-parser/maintainers @pest-parser/triage finds the extension useful in its current form and champions this PR, I think it's ok to go forward with it. Otherwise, it will be better to extend the meta grammar with a feature that is not achieved using derive generators, such as module-level scoping as sketched out in #660 .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've got no big concerns here. It's a simplistic form of code reuse, to be sure, but it's sufficient for simple cases and imo clear about its limitations.
Some minor impl nits and a few questions about semantics; I'll defer to @tomtau on what should block merge.
} | ||
|
||
/// Get path relative to `path` dir, or relative to root path | ||
fn partial_path(path: Option<&PathBuf>, filename: &str) -> PathBuf { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should take Option<&Path>
instead. That might just work out at the call site, or it might require &*
or .as_deref()
, I'm not sure.
fn partial_path(path: Option<&PathBuf>, filename: &str) -> PathBuf { | ||
let root = match path { | ||
Some(path) => path.parent().unwrap().to_path_buf(), | ||
None => join_path("./"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since join_path
looks for the presence of a file to choose between the manifest dir or source dir, this is going to always use the src
dir.
We should deliberately pick one as the "location" of attribute-inline grammars, or perhaps a better choice, just disallow include!
.
Threading up an error from here might be a bigger change, unfortunately.
// Add .pest suffix if not exist | ||
let mut filename = filename.to_string(); | ||
if !filename.to_lowercase().ends_with(".pest") { | ||
filename.push_str(".pest"); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's possible to create file extension less files, so adding an extension on automatically is probably not a great choice. If we do want to add an extension, it should be done via conversion to and then modification via PathBuf
rather than string manipulation.
@@ -45,34 +81,16 @@ pub fn derive_parser(input: TokenStream, include_grammar: bool) -> TokenStream { | |||
|
|||
let mut data = String::new(); | |||
let mut path = None; | |||
let mut has_use = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be has_include
now.
if has_use { | ||
// Re-parse the data again, after replacing the `use` statement | ||
pairs = match parser::parse(Rule::grammar_rules, &data) { | ||
Ok(pairs) => pairs, | ||
Err(error) => panic!("error parsing \n{}", error.renamed_rules(rename_meta_rule)), | ||
}; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doing it this way rather than in a loop means that only a single layer of include!
will be resolved; a include!
of a file with an include!
won't work.
At a minimum we need a test for this case. Ideally we'd make it work, but so long as it results in an error rather than silently causing corruption it's not too bad.
@tomtau Okey, I get it. |
@huacnlee I think one potential use case may be in contexts where one cannot use Rust derive generators. For example:
So in the current form, it will also need to add support for |
* Add doc for load multiple pest files and `include!` syntax. Ref: - pest-parser/pest#759 - pest-parser/pest#758 * Apply suggestions from code review --------- Co-authored-by: Tomas Tauber <[email protected]>
Resolve #197 #333
Example
base.pest
json.pest
Will same as: