eclipse-viatra-bot
commented
3 months ago By Zoltan Ujhelyi on Oct 10, 2023 10:37
As we have discussed today, we could aim for the following:
For the negative-recursion warning we could use a dedicated @SafeNegativeRecursion annotation to say the developer have checked the recursion and it works in the context of the given pattern (these checks cannot be done statically, so a specialized feature is necessary).
The EObjects inside the pattern we should be more careful about using such an annotation as it might make the specialized validation for local search/rete more complex than it should be and the valid set of cases could have been identified manually. We should think about to avoid having this feature backed in a way we might have to support indefinitely. Let me think about this.
| --- | --- | | Bugzilla Link | 582522 | | Status | NEW | | Importance | P4 enhancement | | Reported | Oct 09, 2023 13:18 EDT | | Modified | Oct 11, 2023 03:54 EDT | | Reporter | Gabor Bergmann |
Description
Some pattern language diagnostic markers are intended to safeguard layperson end users from making mistakes that would lead to undesired or undefined behaviour. It would be desirable to allow a more informed user, one who knows what they are doing, to explicitly assume responsibility for them. This may allow VQL code to be generated and matchers to be initialized even for patterns which would otherwise receive validation errors.
A fully general solution would both make diagnostic levels configurable in general (globally or per project) as well as allow the user to manually declare instances where rules should be ignored.
However, at the very minimum, a few commonly frustrating validator rules should have associated pattern annotations to disable them:
The minimal solution could look as simple as a pattern annotation @IgnoreError(issueCode = "recursive_pattern_call")