Expose raw byte position in position information.

[samhocevar]

In some cases it may be desirable to know the byte offset in addition
to the line / column information, for instance when parsing binary
files, or when feeding the parser with partial data.

[samhocevar]

This commit changes the API so I am not sure it is acceptable
as is. However the feature is desirable for my purposes, and I
found out it was easier to modify the PEGTL rather than implement
a byte tracking mechanism using additional state variables, which
I would then have to add to every parser needing it.

I am also not sure of how to format the information (or whether I should
ignore it) in position_info::operator<<.

If this does not fit within your overall plans, maybe you can suggest a
more elegant solution?

[coveralls]

Coverage remained the same at 100.0% when pulling e5f8968 on lolengine:byte-position-in-input into 84a64ef on ColinH:master.

[ColinH]

Thanks for the pull request, I'll not merge it right now because it might interfere with some other things that we have planned, but keep it as reminder and for possible future inclusion if sufficiently independent of these other changes.

[ColinH]

Do you later use the byte position programmatically, or do you only need the human-readable form in the exception message?

[samhocevar]

I use the byte position programmatically, yes.

My current use case here is the creation of a transpiler that does not need an intermediate AST. The parser analyses the input and marks parts of the code using their byte offsets. A post-process then uses search/replace to perform the language transformation, and if the replaced chunk changes the size, offsets located after it get updated. Using line/column notation would make the search/replace work more complex.

[ColinH]

Ok, thanks, another small question: Do you ever need the byte offset together with column and line, or do you not need the column and line in cases where you use the byte offset?

[samhocevar]

In my case, unless I am parsing binary data, I think I always need column and line in order to provide meaningful error reporting, regardless of whether my action class uses the byte offset.

[ColinH]

I've been trying to make this more flexible, to not always keep all three numbers, but it seems to be more work than anticipated, and only for a small optimisation. Your pull-request is now unfortunately out of date, but some of the changes will be simpler with the latest commits. I will now look into re-doing this.