Closed rkaminsk closed 11 months ago
- The constructor of the tag is passed an iterator from which a location can be computed. My current workaround is to store the iterator in a std::any and do the mapping later. However, I am not a fan of using this type. I add a patch with a proposal to pass the state to the tag constructor, below.
That seems like a sensible addition. If you want, you can turn the patch into a PR, by also adding a test and documentation. (And incorporate the fix for 2.)
- Somehow the iterator passed to the tag is off by one. See the example below reproducing the issue.
Fixed.
- I don't like to use lexy::bind and rather use lexy::callback with lambdas. Would it be possible to have a convenience version that also receives the parse state?
I have added lexy::callback_with_state
for that purpose.
Thanks, for the two additions! I'll open a PR, too. It can take 2 to 3 weeks though.
I have a grammar for which I want to track locations, while building the representation. For this, I use the parse state to do the mapping from input iterators to line/column numbers on the fly. This works well but for operators there are some issues (that have workarounds).
std::any
and do the mapping later. However, I am not a fan of using this type. I add a patch with a proposal to pass the state to the tag constructor, below.lexy::bind
and rather uselexy::callback
with lambdas. Would it be possible to have a convenience version that also receives the parse state?Next comes the example code. It's a bit lengthy but self contained and runnable.
Patch proposal to pass the state to the constructor of the operator tag (having generic tags might also be an option):