feat: expose issue error offsets#1339
Conversation
| } | ||
|
|
||
| // Source returns the source associated with the issues. | ||
| func (i *Issues) Source() Source { |
There was a problem hiding this comment.
Usually the best way to take care of this is to preserve the Source by calling cel.CompileSource and then performing these operations in terms of the Issues and Source values. This is usually more guaranteed to be correct than poking into the internal Issues state.
There was a problem hiding this comment.
Ok ,makes sense. Seems the preferred pattern is for callers to create/preserve a Source, call CompileSource or ParseSource, and then map each issue’s Error.Location through Source.LocationOffset, rather than exposing more of the internal Issues state.
Would you prefer that I close this PR, convert it into docs/example coverage for that usage pattern, or narrow it to a smaller convenience API if there is still a gap worth covering?
2 participants
What changed
Issues.Source()for the source attached to parse/check issues.Issues.ErrorOffset()andIssues.ErrorOffsetRange()for raw error positions.Why
Callers that embed CEL in a larger document can map CEL errors back to their own source ranges without parsing display strings.
Fixes #189.
Testing