Skip to content

Conversation

vlad20012
Copy link
Contributor

@vlad20012 vlad20012 commented Jan 16, 2023

StubBasedPsiElementBase.getStubOrPsiChild(IStubElementType) works faster than usual PsiTreeUtil.getStubChildOfType. It can be used if the child rule does not have rules extending it and if there are exact types for stub element types.

generate = [
  exact-types = "elements"
  fast-stub-child-accessors = "yes"
]

With such configuration, Grammar-Kit will generate such implementations for PSI accessors for stubbed elements:

public Element4 getElement4() {
  return notNullChild(getStubOrPsiChild(ELEMENT_4));
}

`getStubOrPsiChild(IStubElementType)` works faster than usual `MyPsiTreeUtil.getStubChildOfType`.
It can be used if the child rule does not have rules extending it and if there are exact types for stub element types.

```
generate = [
  exact-types = "elements"
  fast-stub-child-accessors = "yes"
]
```

With such configuration, Grammar-Kit will generate such implementations for
PSI accessors for stubbed elements:

```
public Element4 getElement4() {
  return notNullChild(getStubOrPsiChild(ELEMENT_4));
}
```
@gregsh
Copy link
Collaborator

gregsh commented Jul 14, 2023

FTR

Why have a separate flag? Let us always go the fast route

It is not always clear whether there is a possibility. If generate.exact-types = "elements" or "all", that is. But if generate.elements = "no", then it is not clear, without the option it is impossible to understand ("does not work" means that the generated code will not compile). You can make it so that when it is clear, then it works without the option.
Apparently, when I wrote, I did not immediately understand that it always works with generate.exact-types

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.

2 participants