Skip to content
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

Open
wants to merge 16 commits into
base: master
Choose a base branch
from

Conversation

amaanq
Copy link

@amaanq amaanq commented Mar 2, 2023

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

@amaanq amaanq force-pushed the master branch 3 times, most recently from 2028a57 to 13e93b5 Compare March 2, 2023 10:03
@amaanq
Copy link
Author

amaanq commented Mar 4, 2023

Ping @drom, just hoping you see this! :)

@drom
Copy link
Member

drom commented Mar 4, 2023

Thank you for picking up the project @amaanq . LGTM
Let me know when you are ready to merge.

@amaanq
Copy link
Author

amaanq commented Mar 4, 2023

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?

Copy link
Member

@drom drom left a 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 ;)

.eslintrc.js Outdated Show resolved Hide resolved
strategy:
fail-fast: true
matrix:
os: [macos-latest, ubuntu-latest]
Copy link
Member

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.

Copy link
Author

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?

Copy link
Member

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.

Copy link
Author

@amaanq amaanq Mar 4, 2023

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

@amaanq
Copy link
Author

amaanq commented Mar 4, 2023

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 ;)

Sorry about that 😅 but most of the changes would sort-of depend on each other, with the exception of the manifest/dotfile updates

@drom
Copy link
Member

drom commented Mar 4, 2023

@amaanq BTW i hope you are looking into the latest FIRRTL spec https://github.com/chipsalliance/firrtl-spec/releases/tag/v1.2.0

@amaanq
Copy link
Author

amaanq commented Mar 4, 2023

@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

@drom
Copy link
Member

drom commented Mar 4, 2023

@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

@amaanq
Copy link
Author

amaanq commented Mar 4, 2023

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?

@amaanq
Copy link
Author

amaanq commented Mar 4, 2023

The spec pdf still has these removed items, and no mentions of the const type qualifier FYI (same with the ANTLR grammar), so idk where that would go

@@ -0,0 +1,5 @@
/test
Copy link
Member

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

Copy link
Author

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

Package.swift Show resolved Hide resolved
@@ -1,36 +0,0 @@
#!/usr/bin/env node
Copy link
Member

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?

Copy link
Author

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

bindings/node/binding.cc Show resolved Hide resolved
bindings/node/index.js Show resolved Hide resolved
bindings/rust/build.rs Outdated Show resolved Hide resolved
@@ -0,0 +1,2518 @@
{
Copy link
Member

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?

Copy link
Author

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

Copy link
Member

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

Copy link
Author

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:
image

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)

Copy link
Member

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?

Copy link
Author

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 @@
[
Copy link
Member

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>
Copy link
Member

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.

src/scanner.cc Outdated Show resolved Hide resolved
@drom
Copy link
Member

drom commented Mar 5, 2023

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?

Agree, let's limit this PR to v1.2.0 spec. And make all radical changes when v2.0 will be out.

package.json Outdated Show resolved Hide resolved
bindings/node/binding.cc Show resolved Hide resolved
@@ -0,0 +1,2518 @@
{
Copy link
Member

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

@amaanq amaanq requested a review from drom March 6, 2023 07:31
optseq('<', $.intLit, '>'),
optseq('<', '<', $.intLit, '>', '>')

module: $ => choice(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@amaanq
Uh, This is total revamping of content, style, organization, and structure.
Could you summarize factual changes?
What bugs it fixes?
What features where added?
For example, does it fix #2 ?

Copy link
Author

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

  1. 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.

  2. better distinguishing of escape sequences

  3. add optional const qualifier support in port

  4. 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.

  5. yes, when-else is fixed, see:
    image

  6. 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)

  7. use snake_case over camelcase as is convention in tree-sitter grammars

  8. ensure every FIRRTL file parses successfully and correctly

  9. fill out docs as best as possible in manifests and libraries/packages

  10. add swift package

  11. format other files like rust, swift header, c/c++ based on appropriate standards

  12. update tests & ci as unix-like work together just fine, then windows is its own thing

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also added support to vim/neovim for auto detection of FIRRTL files so anyone who installs the grammar (after I add it to nvim-treesitter after this is merged) will have highlights, code folding, and indents working out of the box :)

See:
Peek 2023-03-09 21-23

@amaanq
Copy link
Author

amaanq commented Mar 10, 2023

Just an FYI with the generated files, after this is merged the .gitattributes file will auto hide diffs from those for any future commits/PRs

...and as you can see in the failing CI, your eslint config still has quite some complaints, e.g.
image
image

I updated package.json accordingly for this


/* eslint camelcase: 0 */
/* eslint no-undef: 0 */
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants