You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
| --- | --- |
| 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:
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.
I was thinking about the issue of EObject checking, and I am okay with including a beta-grade, open-to-change-without-any-prior-notice workaround. Of course, we should clearly document in the annotation documentation that it is subject to change.
| --- | --- |
| 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")
The text was updated successfully, but these errors were encountered: