Repository navigation
feat(rome_css_parser): CSS parser #4682 - #4724
Conversation
✅ Deploy Preview for docs-rometools canceled.
|
f0fea7f to
fb5fb02
Compare
Parser conformance results on ubuntu-latestjs/262
jsx/babel
symbols/microsoft
ts/babel
ts/microsoft
|
fb5fb02 to
190ed1c
Compare
| use rome_css_syntax::CssSyntaxKind::*; | ||
| use rome_parser::Parser; | ||
|
|
||
| pub(crate) fn parse_root(p: &mut CssParser) { |
There was a problem hiding this comment.
It's the entry point for syntax parsing.
| Undefined, | ||
| } | ||
|
|
||
| pub fn run(test_case: &str, _snapshot_name: &str, test_directory: &str, outcome_str: &str) { |
There was a problem hiding this comment.
It's a copy of the JSON test spec.
I'd like to write tests the same way we use in the JS parser. But I'm unsure what is the best way. I think that we can combine both approaches.
There was a problem hiding this comment.
Personally, I don't like the test suite of the JS parser:
- we have to run two commands in order to run the tests
- we always need to tweak the test generator parser to accommodate new things - like parser options, which is becoming quite difficult
The best way, personally, would be just to write a file to test and then check the snapshot with insta; of course the testing suite will do much more, but that's the gist of it.
| } | ||
|
|
||
| /// Try to eat a specific token kind, if the kind is not there then adds an error to the events stack. | ||
| fn expect(&mut self, kind: Self::Kind) -> bool { |
There was a problem hiding this comment.
It seems that we don't need any special behavior for comments here. When allow_comments is true, it implies that COMMENT and MULTILINE_COMMENT kinds are considered as trivia.
tools/crates/rome_json_parser/src/token_source.rs
Lines 62 to 71 in 1dcd62b
Summary
Initial implementation of
CssTokenSourceandCssParserfor the CSS parser.Added
CssParserOptionswhich has anallow_single_line_commentsoption. This allows the writing of single line comments in CSS syntax.Test Plan
cargo test