NestingLevel constraint?

["Larry Golding \(Comcast\)" <larrygolding@comcast.net>]

In the old days, when we had codeFlowLocation.kind, the "call" and "callReturn" values for kind naturally forced the sequence of code flow locations into a tree structure (the call tree).

 

Now kind is gone, replaced by nestingLevel, and you can simulate the old call/return nesting by ensuring that nestingLevel either stays the same, increases by 1, or decreases by 1 between successive locations. For example, this sequence of nesting levels:

 

[ 0, 0, 1, 1, 2, 2, 1, 1, 0, 0 ]

 

… leads to a call tree like this:

 

Step 1 (in main)

Step 2 (calls funcA)

  Step 3

  Step 4 (calls funcB)

    Step 5

    Step 6 (returns from funcB to funcA)

  Step 7

  Step 8 (returns from funcA to main)

Step 9

Step 10

 

BUT! As the spec stands today, nothing stops you from creating a code flow with this sequence of nesting levels:

 

[ 0, 0, 5, 5, 9, 9, 7, 7, 2, 2 ]

 

How should we deal with that? There are three choices:

 

1. Prohibit it in the spec. A consumer who encounters a sequence like this is entitled to report an error and not even try to render it.
2. Allow it in the spec, and assign semantics to the size of the difference from one nesting level to the next.
3. Allow it in the spec, but interpret any increase in nesting level the same as a single indent, and any decrease as a single outdent.

 

If we chose Option 3, then a viewer would be entitled to interpret [ 0, 0, 5, 5, 9, 9, 7, 7, 2, 2 ] as exactly equivalent to [ 0, 0, 1, 1, 2, 2, 1, 1, 0, 0 ].

 

Michael: At the moment, Chris and I have chosen Option 3 in implementing the V2 SARIF Viewer.

 

Whichever we choose, we need to document it.

 

Thoughts?

 

Larry