mergiraf/mergiraf
mergiraf/mergiraf
9
213
Fork 45
Code Issues 51 Pull requests 7 Releases 19 Activity Actions

fix: Switch from grammar_name to kind #561

Merged
ada4a merged 7 commits from lang_profile_name_validation into main 2025-08-18 20:17:21 +02:00
Conversation 1 Commits 7 Files changed 18 +389 -189
wetneb commented 2025-08-02 18:08:46 +02:00
Owner
Copy link

Work in progress because this seems to be rejecting node names that are actually valid (they can be returned with mgf_dev parse). More investigation is required.

For #489.

Work in progress because this seems to be rejecting node names that are actually valid (they can be returned with `mgf_dev parse`). More investigation is required. For #489.
tests: Enable the name inconsistency check as a test
Some checks failed
/ test (pull_request) Failing after 26s
Details
97dca8af1d
wetneb force-pushed lang_profile_name_validation from 97dca8af1d to bc8a83ff25 2025-08-17 09:39:37 +02:00 Compare
wetneb changed title from WIP: tests: validate node type and field names from language profiles to fix: Switch from grammar_name to kind 2025-08-17 09:40:34 +02:00
clippy
All checks were successful
/ test (pull_request) Successful in 41s
Details
d58605ae6c
wetneb commented 2025-08-17 09:48:19 +02:00
Author
Owner
Copy link

So, this was a rather big can of worms.

The reason why some grammar names couldn't be looked up is that there is indeed a difference between the kind of a node (the user-facing string that determines the node type) and its grammar name which is the internal naming of the rule that generated it. In most cases, those names are the same, but in general they aren't (for instance when using aliases in the grammar definition).

For some reason, I chose to use the "grammar name" when building AstNodes, but it was a bad idea since those names are not the ones that grammar authors intend to expose to grammar users. For instance, this creates an inconsistency with the tree-sitter queries we use, since they rely on kinds, not grammar names.

So, the first steps of this PR consist in migrating to use kinds instead of grammar names. It's a rather annoying change to do, since we refer to grammar names in a lot of places. I have tried to fix the language profiles accordingly, but it's not an easy change to make, and it can well be that I forgot some updates.

The second step of this PR consists in introducing the check I wanted to do in the first place, validating that the kinds we use are indeed valid.

So, this was a rather big can of worms. The reason why some grammar names couldn't be looked up is that there is indeed a difference between the *kind* of a node (the user-facing string that determines the node type) and its *grammar name* which is the internal naming of the rule that generated it. In most cases, those names are the same, but in general they aren't (for instance when using aliases in the grammar definition). For some reason, I chose to use the "grammar name" when building `AstNode`s, but it was a bad idea since those names are not the ones that grammar authors intend to expose to grammar users. For instance, this creates an inconsistency with the tree-sitter queries we use, since they rely on kinds, not grammar names. So, the first steps of this PR consist in migrating to use *kinds* instead of grammar names. It's a rather annoying change to do, since we refer to grammar names in a lot of places. I have tried to fix the language profiles accordingly, but it's not an easy change to make, and it can well be that I forgot some updates. The second step of this PR consists in introducing the check I wanted to do in the first place, validating that the kinds we use are indeed valid.
Update docs
All checks were successful
/ test (pull_request) Successful in 43s
Details
bc3a327823
ada4a approved these changes 2025-08-18 20:16:54 +02:00
ada4a merged commit c104c72c45 into main 2025-08-18 20:17:21 +02:00
ada4a deleted branch lang_profile_name_validation 2025-08-18 20:17:22 +02:00
Sign in to join this conversation.
Reviewers
No reviewers
ada4a
Labels
Clear labels   
Compat/Breaking

Breaking change that won't be backward compatible

  
Kind
Bad merge
Examples where the merging algorithm doesn't work as well as it should

  
Kind
Bug
Something is not working

  
Kind
Documentation
Documentation changes

  
Kind
Enhancement
Improve existing functionality

  
Kind
Feature
New functionality

  
Kind
New language

  
Kind
Security
This is security issue

  
Kind
Testing
Issue or pull request related to testing

  
Priority
Critical
The priority is critical

  
Priority
High
The priority is high

  
Priority
Low
The priority is low

  
Priority
Medium
The priority is medium

  
Reviewed
Confirmed
Issue has been confirmed

  
Reviewed
Duplicate
This issue or pull request already exists

  
Reviewed
Invalid
Invalid issue

  
Reviewed
Won't Fix
This issue won't be fixed

  
Status
Abandoned
Somebody has started to work on this but abandoned work

  
Status
Blocked
Something is blocking this issue or pull request

  
Status
Need More Info
Feedback is required to reproduce issue or to continue work

No labels
Compat/Breaking
Kind
Bad merge
Kind
Bug
Kind
Documentation
Kind
Enhancement
Kind
Feature
Kind
New language
Kind
Security
Kind
Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: mergiraf/mergiraf#561
No description provided.
Delete branch "lang_profile_name_validation"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?