-
Sub-task
-
Resolution: Unresolved
-
P4
-
17, 18
An @IR rule can specify a blacklist with the failOn attribute. An idea would be to add the opposite of a whitelist attribute, for example, an attribute "accept" which fails when a non-whitelisted node is found.
To avoid having to list all common nodes that are always present (like ParmNodes, ProjNode or the RootNode), one could also think about adding a skeleton pattern which matches all these nodes which the user can then feed into "accept":
@Test
@Arguments({Argument.RANDOM_EACH, Argument.RANDOM_EACH})
@IR(accept = {IRNode.SKELETON, IRNode.SUB})
public int simpleTwo(int a, int b) {
return a - b;
}
The IRNode.SKELETON could also be applied by default such that the user does not need to specify it explicitly. The challenge will be to find a good skeleton to avoid false positives while not being too conservative by adding a lot of nodes.
To avoid having to list all common nodes that are always present (like ParmNodes, ProjNode or the RootNode), one could also think about adding a skeleton pattern which matches all these nodes which the user can then feed into "accept":
@Test
@Arguments({Argument.RANDOM_EACH, Argument.RANDOM_EACH})
@IR(accept = {IRNode.SKELETON, IRNode.SUB})
public int simpleTwo(int a, int b) {
return a - b;
}
The IRNode.SKELETON could also be applied by default such that the user does not need to specify it explicitly. The challenge will be to find a good skeleton to avoid false positives while not being too conservative by adding a lot of nodes.