-
-
Notifications
You must be signed in to change notification settings - Fork 217
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 Grammar Include Support #457
Conversation
Hi Liam, Thanks for the putting in the work to prototype this! Adding support for imports is something we've thought about over the years, but have hesitated to implement. Mainly, my concern is — what happens if someone is trying to load the grammar via This is a feature that I'd be happy to add, but if we're going to do it, I'd like to make sure we think it through and implement it fully. If it's something you're up for, we could collaborate on it. I'll leave some notes on #286 about some of the things I'd like to address in a complete implementation. |
Whoops, didn't mean to close this PR. I think we keep it open and iterate on it. |
Hi Patrick, I'd love to collaborate, this as you mentioned was just a fix to get it working for my use case but I was keen to bring it in language as opposed to a CLI-only option. ohm.grammar(`
include './foo.ohm'
G {
...
}
`, {
fetchGrammar(relativeUrl) {
return fs.readFileSync(relativeUrl, import.meta.url, 'utf-8');
}
}) This is a good starting point. Which allows the user to provide the method of resolution of the imported grammar. However, I'd expect the most common implementation to be:
Which I believe we could provide default implementations for e.g. Next steps
We then can evaluate the above and see how this would play with TypeScript and then make a new iteration with new learnings. |
This reverts commit 11e40ac.
@pdubroy I'm trying to get the grammar working with the existing unit tests. However, I'm having issues with the test setup. Test Steps
|
A couple of the tests depend on the generated bundles, so I think you need to run (It's not ideal — maybe we should run it |
That makes sense, I just ran a
Do these usually fail? |
Yes, those are marked as known failures. The output is slightly confusing but ava allows you to mark tests as "known failures" so that |
Interesting, thanks for the insight. That makes sense to why I'm getting the return code 0. I'm looking at implementing unit tests now for the grammar modifications. |
@pdubroy It would be good to do a partial review now. All tests are passing ✔️ Side notes:
|
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.
Looks like a great start! I have a few questions, and a request to change the implementation a bit.
include | ||
= "include" | ||
|
||
relativeFilePath |
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.
What's the reason for choosing to allow these specific characters? Maybe I'm wrong, but it seems like it may be overly restrictive.
An alternative would be for Ohm to be completely agnostic about paths, and accept any character inside the quotes.
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 is following security standards to always use an allowlist when you know the expected content format. If you want to accept the risk and open it to any character between the quotes we can do that.
@@ -1382,22 +1382,22 @@ describe('bootstrap', test => { | |||
const ns = ohm.grammars(ohmGrammarSource); | |||
|
|||
test('it can recognize arithmetic grammar', t => { | |||
assertSucceeds(t, ns.Ohm.match(arithmeticGrammarSource, 'Grammar')); |
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.
Were these changes necessary, or is this an unrelated cleanup?
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 we added new Document
rule to grammar the default rule is now Document
, I feel the tests should be validating against the new grammar and not a sub-rule (e.g. Grammar
) of the main grammar. Hence the change and resulting fixes to array accesses below.
Fixes #286
I've implemented a fix that prevents VS Code complaining about LF vs CLRF line endings. This uses the solution provided in this article and enforces LF line endings.
Implementation (2.0)
ohm-cli
include '...'
in the ohm-js grammarinclude
statement in the grammarDocument
,Includes
, andInclude
rulesoptions
object for theohm.grammar
function inohm-js
fetchImport
that is provided via optionaloptions
object (Add circuit breaker for preventing infinite loop includes).node.js
and.browser.js
file type support (optional)Thoughts