-
Notifications
You must be signed in to change notification settings - Fork 8
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
feat: complete the grammar and tidy up the repo #6
base: master
Are you sure you want to change the base?
Conversation
2028a57
to
13e93b5
Compare
Ping @drom, just hoping you see this! :) |
Thank you for picking up the project @amaanq . LGTM |
Sure thing, it's ready imo. For the publish actions, just add your npm token as a secret in the repo, and does emailing you work for my crates secret? |
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 would prefer a set of more focused PRs
It is rather hard to review so many unrelated changes.
It all looks good to me from 11KM height ;)
strategy: | ||
fail-fast: true | ||
matrix: | ||
os: [macos-latest, ubuntu-latest] |
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.
We should keep 3 separate CI test plans Linux / MacOS / Windows as it was before.
Also run on broad matrix of NodeJS versions.
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 like the broad matrix of NodeJS versions idea, but what's wrong with consolidating the OS tests to one workflow file?
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.
Linux plan usually runs very fast and if the badge is green it make sense to wait for MacOS.
MacOS and Windows plans needed mostly to fight respected OS issues.
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.
Linux plan usually runs very fast and if the badge is green it make sense to wait for MacOS. MacOS and Windows plans needed mostly to fight respected OS issues.
Well, the mac/windows ones don't take that much longer, and I do take into account differences in the OS (at least for Windows - see the scripts in package.json, Mac is Unix-like so it's ok), see an example of the CI badge here: https://github.com/amaanq/tree-sitter-kdl
Sorry about that 😅 but most of the changes would sort-of depend on each other, with the exception of the manifest/dotfile updates |
@amaanq BTW i hope you are looking into the latest FIRRTL spec https://github.com/chipsalliance/firrtl-spec/releases/tag/v1.2.0 |
Is there anything new as far as syntax/file structure goes? I did refer to this when making my changes |
There are some syntax changes in master https://github.com/chipsalliance/firrtl-spec/blob/main/revision-history.yaml#L7-L14 |
Oh wow, quite some changes. Do we want to reflect these changes in the grammar? Like the removal of fixed point types, partial connections, and validif? |
The spec pdf still has these removed items, and no mentions of the |
@@ -0,0 +1,5 @@ | |||
/test |
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.
instead .npmignore
I would keep the files
section inside package.json
to list what ned to be published to NPM
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.
Hmm gotcha, I do think being a bit more explicit here rather than reading through package.json
to find the published files is easier on the user/dev, totally your call though
@@ -1,36 +0,0 @@ | |||
#!/usr/bin/env node |
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.
Why have you deleted instal
script?
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 don't exactly know when you made this repo, but it seems to be quite a while ago from before tree-sitter handled installation for a repository. If you check out my branch and run npm install, it seems to run almost the same thing as this did, if not anything more/new
@@ -0,0 +1,2518 @@ | |||
{ |
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.
why do we commit generated files to git?
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 is so those that want to install the parser do not need to generate from the grammar file, which nvim-treesitter (neovim plugin) does. This way, all one needs to install this parser is a C compiler, which reduces time spent on installing and resources as well, at the cost of having this file in the repo. Diffs and PRs won't show changes to these files because of the .gitattributes file I added if that's a concern of yours
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 am for keeping only source code under source revision control.
Published NPM package will include all generated files.
Same for Cargo and other Package managing systems.
Keeping large generated files under source code revision control leading to confusion and mismatch IMHO
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.
nvim-treesitter, helix, emacs, nixpkgs, and whatever other editor/pkg management system almost always pulls the git version as oftentimes repos don't publish often enough to fix bugs/add features. I would like to say that the .gitattributes file prevents unnecessary noise in viewing diffs / changes online. See example here:
So, I'd like to counter the idea that this would lead to confusion/mismatches, provided that PRs changing the grammar also update the generated files (ideally with a "generate" commit of sorts)
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.
Git is not a very good "package manager". If some systems can't download / untar NPM package we can create separate branch "package" or "release" or something, similar to "gh-pages" where we will "publish" releases of generated C, H, JSON files (no source) and that would be a "pure-man package manager". How about this?
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 don't particularly like that as any sources that leverage tree-sitter packages have it configured to either generate from npm if there's no generated files, or just simple compile parser.c if it's present.
Just doing a quick check in nvim-treesitters parsers.lua list, about 30 of the ~200 languages we support require this generation process. So for the most part, grammars contain these files so people on lower end machines won't struggle as much and the only dependency is a C99 compiler then (making it much more cross-platform/universally available)..
Of course it's your final call as it's your repo, but to me it'd have far more benefits than downsides to add them here
@@ -0,0 +1,1507 @@ | |||
[ |
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.
why do we commit generated files to git?
src/parser.c
Outdated
@@ -0,0 +1,17178 @@ | |||
#include <tree_sitter/parser.h> |
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.
why do we commit generated files to git?
It is not the source code.
Agree, let's limit this PR to v1.2.0 spec. And make all radical changes when v2.0 will be out. |
@@ -0,0 +1,2518 @@ | |||
{ |
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 am for keeping only source code under source revision control.
Published NPM package will include all generated files.
Same for Cargo and other Package managing systems.
Keeping large generated files under source code revision control leading to confusion and mismatch IMHO
optseq('<', $.intLit, '>'), | ||
optseq('<', '<', $.intLit, '>', '>') | ||
|
||
module: $ => choice( |
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.
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.
Been a while now, but let me summarize it from memory as best as I can
-
mux and other reserved keywords could not be used as identifiers, however in the main repository (firrtl/regress/FPU.fir) mux is used as an identifier, so adding the keyword_identifier rule aliased to identifier and inlining it solves this.
-
better distinguishing of escape sequences
-
add optional const qualifier support in port
-
extract any rules in statements into their own rule, which then enables setting statement as a supertype. supertypes allow us to use them in a query, but hides them in a node - inline doesn't allow us to use them in a query as well.
-
make queries (imo) perfect to neovim treesitter standards (we will standardize this with helix/other editors soon, as Max the tree-sitter creator & others have agreed last-wins is best - aka Neovim convention)
-
use snake_case over camelcase as is convention in tree-sitter grammars
-
ensure every FIRRTL file parses successfully and correctly
-
fill out docs as best as possible in manifests and libraries/packages
-
add swift package
-
format other files like rust, swift header, c/c++ based on appropriate standards
-
update tests & ci as unix-like work together just fine, then windows is its own thing
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.
|
||
/* eslint camelcase: 0 */ | ||
/* eslint no-undef: 0 */ |
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-undef
and no-unused-vars
was in this file because they are specific to this file only.
This PR has a lot of changes, so do take your time to look over them. But I hope you'll be pleased with this, as I've fixed several bugs and added a much smoother CI/CD action, as well as general touches making the repo look a lot nicer. I've decided to bump the version to v0.8.0 accordingly, for the actions you can set the secrets yourself if you choose to, just let me know and I can send/email you the CARGO token