-
Notifications
You must be signed in to change notification settings - Fork 653
refactor(rome_js_parser): Extract shared parser infrastructure #3833
Conversation
✅ Deploy Preview for docs-rometools canceled.
|
!bench_parser |
Parser conformance results on ubuntu-latestjs/262
jsx/babel
symbols/microsoft
ts/babel
ts/microsoft
|
Comparing refactor(rome_js_parser): Extract shared parser infrastructure Snapshot #5 to median since last deploy of rome.tools.
1 page tested
|
Chrome Desktop | iPhone, 4G LTE | Motorola Moto G Power, 3G connection |
---|---|---|
Most significant changes
27 other significant changes: JS Parse & Compile on Chrome Desktop, Largest Contentful Paint on Motorola Moto G Power, 3G connection, First Contentful Paint on Motorola Moto G Power, 3G connection, Total Blocking Time on Chrome Desktop, Total CSS Size in Bytes on Chrome Desktop, Total CSS Size in Bytes on iPhone, 4G LTE, Total CSS Size in Bytes on Motorola Moto G Power, 3G connection, Time to Interactive on Motorola Moto G Power, 3G connection, Total Page Size in Bytes on Chrome Desktop, Total Page Size in Bytes on iPhone, 4G LTE, Total Page Size in Bytes on Motorola Moto G Power, 3G connection, Time to Interactive on Chrome Desktop, Largest Contentful Paint on Chrome Desktop, First Contentful Paint on Chrome Desktop, Number of Requests on Motorola Moto G Power, 3G connection, Number of Requests on Chrome Desktop, Number of Requests on iPhone, 4G LTE, Speed Index on Motorola Moto G Power, 3G connection, Time to Interactive on iPhone, 4G LTE, Largest Contentful Paint on iPhone, 4G LTE, First Contentful Paint on iPhone, 4G LTE, Speed Index on Chrome Desktop, Total HTML Size in Bytes on Chrome Desktop, Total HTML Size in Bytes on iPhone, 4G LTE, Total HTML Size in Bytes on Motorola Moto G Power, 3G connection, Lighthouse Performance Score on Motorola Moto G Power, 3G connection, Lighthouse Performance Score on Chrome Desktop
Calibre: Site dashboard | View this PR | Edit settings | View documentation
Parser Benchmark Results
|
d596ea1
to
df1d539
Compare
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.
No particular concerns, happy to merge it!
span: Option<TextRange>, | ||
/// Reference to a file where the issue occurred | ||
#[location(resource)] | ||
pub(super) file_id: FileId, |
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.
Any chance we could remove FileId
during this refactor? Not a blocker, it would be a nice to have! :)
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'll leave that to you or leo as I have no idea what must be done and I only moved the file around.
Summary
Part of #2351
This PR extracts the shared parser infrastructure into a new
rome_parser
crate.This PR introduces a new
Parser
trait that implements the common parser methods. The internal data used by the trait is wrapped in aParserContext
struct that ensures that access to events and diagnostics is locked down (only few operations are permitted by outside crates because manipulating events risks creating a corrupted events stream).This PR renames the
Parser
struct inrome_js_parser
toJsParser
to avoid name clashes.This PR introduces the new
TokenSource
trait and renames the JavaScript token source struct toJsTokenSource
. The PR further introduces the newBumpWithContext
andNthToken
traits thatTokenSource
's can implement that support different lexing contexts or support lookahead (neither is the case for JSON).Design Decision
I decided to remove the
kind
of theCompletedMarker
and instead read it from theevents
vector to avoid thatCompletedMarker
, and in turn,ParsedSyntax
must become generic overSyntaxKind
. The downside of this decision is that it is possible to callcompleted_marker.kind(parser)
with different parsers, yielding incorrect results if the parser uses a different kind.I consider this a compromise worth taking as this is only a problem if both parsers happen to have the exact same events because indexing into the
events
stream would otherwise fail (or return rubbish).Alternative Designs
My first approach used a
Parser
struct with a genericLanguageParser
type parameter.Where
LanguageParser
would store any language-specific state. It worked reasonably but has the downsides thatParser<JsLanguageParser>
because Rust doesn't allow implementing methods for a struct unowned by the crate.JsLanguageParser
directly was awkward because it required access to theParser
for almost all operations.Test Plan
cargo test