If all the inlining frames are represented in the generated function's GeneratedRangeTree, then it is likely that when GeneratedRangeCallSite is parsed, the sourceIndex is the same as the currently open GeneratedRangeTree's parent's definition (scope) sourceIndex, and the line and column are at small offsets.
I am hesitant to suggest that the decoding tracks the current scope, since I want to avoid storing scopes during decoding for stack trace translation (#256).
It might be that simple delta encoding all three components independently gives better encoding size.
Nested inlining might encode as, say, +HUGE1, -HUGE2, but back-to-back inlining would encode with small deltas.
+HUGE1 and -HUGE2 are at most 1 bits (0.2 vlq digits) longer than the largest absolute indexes. Small deltas would compensate, and works across multiple nearby generated functions that correspond to nearby original source functions (e.g. class methods).
If all the inlining frames are represented in the generated function's GeneratedRangeTree, then it is likely that when GeneratedRangeCallSite is parsed, the sourceIndex is the same as the currently open GeneratedRangeTree's parent's definition (scope) sourceIndex, and the line and column are at small offsets.
I am hesitant to suggest that the decoding tracks the current scope, since I want to avoid storing scopes during decoding for stack trace translation (#256).
It might be that simple delta encoding all three components independently gives better encoding size.
Nested inlining might encode as, say, +HUGE1, -HUGE2, but back-to-back inlining would encode with small deltas.
+HUGE1 and -HUGE2 are at most 1 bits (0.2 vlq digits) longer than the largest absolute indexes. Small deltas would compensate, and works across multiple nearby generated functions that correspond to nearby original source functions (e.g. class methods).