On Thu, 18 Jan 2018 13:24:42 +0000 "Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote: > I'm going to experiment with hooking the opchecker for OP_LEAVESUB to > see if that's another way to implement this. If that works, then I'll > probably stick with that instead of my current attempt, because then > it automatically works for 5.20 to 5.26, in addition to whatever > future perl version eventually provides direct parser APIs for > signatures or attributes. It turns out this doesn't look likely to help. In my current code, I am responsible for calling start_subparse(), among whose responsibilities is to allocate the new CV and set it into PL_compcv. Immediately after I call this I can then inspect the value of PL_compcv and set it into the lexical hints hash, so that other stages of the parser logic can compare whether they're still operating on the actual `async sub`, or some nested (normal synchronous) `sub` within it. If I just get the parser to handle the entire `sub NAME (SIGNATURE) :ATTRS... {BLOCK}` part, then I lose the ability to see PL_compcv directly, so this stops working. I've thought up a few possible approaches into that which involve remembering the height of the save stack and the observation that in the current code, the value of the new PL_compcv gets pushed a certain height above that, so maybe it could be recovered that way. But frankly that way sounds massively fragile, even moreso than any other approach I have here. So I don't think I'll do that. I'm still quite attracted by the idea of getting perl to somehow do the bulk of all the parsing for me, because otherwise I will have to write quite a long and delicate sequence of looking for all the pieces, in the right order, and stringing them all together nicely. It feels like perl ought to be able to do that for me. I wonder if there'd still be a way to make that work. For example, if I could create the new CV and then pass that *in* to the parser somehow, so that start_subblock() can use it, then I can know what its value will be beforehand and set things up. That would make things work while also not needing me to worry about how to drive all the parser pieces. This still wouldn't fix the gap between 5.20 and 5.{whatever version this arrives in}, but it would at least be a start to ensuring subsequent ones work OK, and maybe I can do something special and custom to fill in the gap. -- Paul "LeoNerd" Evans leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/Thread Previous | Thread Next