Comments (12)
Good questions! My guess is that the problem is because of two parsers using one lexer: I must admit that isn't a use case I'd ever considered, which virtually guarantees that it won't work out of the box. I'll take a look!
from grmtools.
OK, so it turns out that past-me was less stupid than current-day-me: CTLexerBuilder::output_path
was designed for this sort of thing but it's quite low-level. So I can fix your build with:
diff --git src/build.rs src/build.rs
index a7fecce..0c93f5a 100644
--- src/build.rs
+++ src/build.rs
@@ -1,7 +1,12 @@
+use std::{env::var, path::PathBuf};
+
use cfgrammar::yacc::{YaccKind, YaccOriginalActionKind};
use lrlex::CTLexerBuilder;
fn main() -> Result<(), Box<dyn std::error::Error>> {
+ let mut outp = PathBuf::new();
+ outp.push(var("OUT_DIR").unwrap());
+ outp.push("parser_lexer.l.rs");
CTLexerBuilder::new()
.lrpar_config(|ctp| {
ctp.yacckind(YaccKind::Grmtools)
@@ -9,43 +14,24 @@ fn main() -> Result<(), Box<dyn std::error::Error>> {
.unwrap()
})
.lexer_in_src_dir("lexer.l")?
+ .output_path(outp.to_str().unwrap().to_owned())
+ .mod_name("lexer_l")
.build()?;
-
+ let mut outp = PathBuf::new();
+ outp.push(var("OUT_DIR").unwrap());
+ outp.push("func_lexer.l.rs");
CTLexerBuilder::new()
.lrpar_config(|ctp| {
ctp.yacckind(YaccKind::Original(YaccOriginalActionKind::GenericParseTree))
.grammar_in_src_dir("func.y")
.unwrap()
})
- .lexer_in_src_dir("func.l")?
+ .lexer_in_src_dir("lexer.l")?
+ .output_path(outp.to_str().unwrap().to_owned())
+ .mod_name("func_l")
.build()?;
Ok(())
}
-// fn main() -> Result<(), Box<dyn std::error::Error>> {
-// CTLexerBuilder::new()
-// .lrpar_config(|ctp| {
-// ctp.yacckind(YaccKind::Grmtools)
-// .grammar_in_src_dir("parser.y")
-// .unwrap()
-// })
-// .lexer_in_src_dir("lexer.l")?
-// .mod_name("parser_lexer")
-// .build()?;
-//
-//
-// CTLexerBuilder::new()
-// .lrpar_config(|ctp| {
-// ctp.yacckind(YaccKind::Original(YaccOriginalActionKind::GenericParseTree))
-// .grammar_in_src_dir("func.y")
-// .unwrap()
-// })
-// .lexer_in_src_dir("lexer.l")?
-// .mod_name("func_lexer")
-// .build()?;
-//
-// Ok(())
-// }
-
diff --git src/main.rs src/main.rs
index b4a80c7..7cfbce0 100644
--- src/main.rs
+++ src/main.rs
@@ -9,8 +9,8 @@ use crate::rt_util::*;
// Using `lrlex_mod!` brings the lexer for `calc.l` into scope. By default the
// module name will be `calc_l` (i.e. the file name, minus any extensions,
// with a suffix of `_l`).
-// lrlex_mod!("parser_lexer.l");
-lrlex_mod!("lexer.l");
+lrlex_mod!("parser_lexer.l");
+//lrlex_mod!("lexer.l");
// Using `lrpar_mod!` brings the parser for `calc.y` into scope. By default the
// module name will be `calc_y` (i.e. the file name, minus any extensions,
// with a suffix of `_y`).
diff --git src/rt_util.rs src/rt_util.rs
index 172796b..64d6b92 100644
--- src/rt_util.rs
+++ src/rt_util.rs
@@ -6,7 +6,7 @@ use lrpar::{Lexeme, lrpar_mod, Node};
use plotters::prelude::*;
lrpar_mod!("func.y");
-lrlex_mod!("func.l");
+lrlex_mod!("func_lexer.l");
#[derive(Debug)]
pub enum DrawableKind<'a> {
@@ -251,4 +251,4 @@ impl<'a> Eval<'a> {
_ => unreachable!(),
}
}
-}
\ No newline at end of file
+}
The use of mod_name
is strictly optional in this case.
I'm not saying that the solution is nice, but at least there is one :) grmtools should, however, have done better at stopping you shooting yourself in the foot in the first place. I'll raise a PR shortly which catches this problem and gives the user a strong hint as to what to do.
Thanks for the bug report!
from grmtools.
And two parser use one lexer (.l
file), additionally.
from grmtools.
What information I received is:
>>> rot is 0;
Lexing error at line 1 column 1.
Unable to evaluate expression.
from grmtools.
Interesting thing is that if each parser uses lexer of there own, error won't happen seemingly.
from grmtools.
I think I know what the problem is. In grmtools an (lrlex) lexer is specialised to a parser. Simplifying a bit: a parser says "lexer, you must use the ID 1234 for tokens of type T". If you generate two parsers using the same lexer, they will tell that parser to use different IDs and it will probably choose whichever was compiled second as the "winner".
Can you try using mod_name
to differentiate the two lexers and tell me if that works?
fn main() -> Result<(), Box<dyn std::error::Error>> {
CTLexerBuilder::new()
.lrpar_config(|ctp| {
ctp.yacckind(YaccKind::Grmtools)
.grammar_in_src_dir("parser.y")
.unwrap()
})
.lexer_in_src_dir("lexer.l")?
.mod_name("parser_lexer")
.build()?;
CTLexerBuilder::new()
.lrpar_config(|ctp| {
ctp.yacckind(YaccKind::Original(YaccOriginalActionKind::GenericParseTree))
.grammar_in_src_dir("func.y")
.unwrap()
})
.lexer_in_src_dir("lexer.l")?
.mod_name("func_lexer")
.build()?;
Ok(())
}
You'll then import the first with lrlex_mod!("parser_lexer")
and the second with lrlex_mod!("func_lexer")
.
If this does work for you, I think what I should do is find a way to detect that the user is trying to use the same lexer twice and warn/error.
from grmtools.
It seems like the configuration of directory has a problem:
couldn't read .../target/debug/build/...-19fd5e8da249b243/out/parser_lexer.rs: No such file or directory (os error 2)
when:
lrlex_mod!("parser_lexer");
| ^^^^^^^^^^^^^^^^^^
|
= note: this error originates in the macro `include` (in Nightly builds, run with -Z macro-backtrace for more info)
from grmtools.
Mea culpa! You'll need to add .l
I think e.g. lrlex_mod!("parser_lexer.l")
.
from grmtools.
Mea culpa! You'll need to add
.l
I think e.g.lrlex_mod!("parser_lexer.l")
.
It didn't work as well.😂
from grmtools.
Ah. If you have a github repo / branch with your project in, can you send me a link? That'll help me debug this.
from grmtools.
Ah. If you have a github repo / branch with your project in, can you send me a link? That'll help me debug this.
GitHub repo is https://github.com/MrZLeo/drawing-lang-compiler.
I have to say this project is in the very beginning phrase of development, so it would be vulnerable in every pieces of code. parser.y
is use for the compiler/interpreter, and func.y
is use for the for-structure that language is going to support. You can see it in main.rs
and rt_util.rs
respectively.
Good luck😂
from grmtools.
Thanks! I'll have a look in the next day or so and get back to you.
from grmtools.
Related Issues (20)
- GDB Support? HOT 5
- Add support for comments in lrlex files HOT 3
- Explain why Copy is required for a type specified %parse-param HOT 7
- Nondeterministic generation of Rust code HOT 2
- Support lex-style definitions HOT 1
- Trying to replicate `tinylang.yy` and `tinylang.l` syntax with `nimbleparse` HOT 5
- Weird that `nimbleparse` works on `java7.y` `java7.l` even though the `GT` symbol in both is different. HOT 1
- Online Yacc/Lex editor/tester HOT 6
- Detailed debug info for reduce/reduce shift/reduce errors? HOT 27
- Docs Question - Optional Prefix to Regular Expressions HOT 5
- lrpar lose info about debug HOT 7
- nimbleparse:Suggestions for outputting information HOT 5
- lrlex: match beginning of line HOT 4
- lrpar:%prec not followed by token name HOT 11
- lpar:Unused rule HOT 6
- Is there a way to pass Conext in `$lexer` when doing action? HOT 3
- How to use the code generated by grmtools as a lib for others to use HOT 6
- Make generated parsers usable on the web HOT 2
- Errors in catching incorrectly terminated productions HOT 4
- Define lexemes in terms of other lexemes HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from grmtools.