Various modules, mostly pragmas, need a way to hook themselfs in at the end of compile time of a given scope, to do things like cleaning up after themselfs. The core currently doesn't provide a way to do that. Various ways of doing it anyway have been implemented nevertheless. They all rely on a lexicalized hints hash (and therefore $^H, a variable strictly for internal use only) and the fact that a localized hints hash is being destroyed right after compiling a block has finished, i.e. during scope_leave. That's bad. Even worse, the trivial implementation of end-of-scope hooks, which relies on a Scope::Guard (or a similar object, giving a callback during DESTROY), doesn't always work on 5.10, where %^H is propagated into string evals, which increments the refcount of the stored objects, preventing their DESTROY methods from firing when you'd expect them to. B::Hooks::EndOfScope avoids this by relying on attaching free magic to %^H, but that's not a very elegant solution either. The following patch implements a new special variable, @{^COMPILE_SCOPE_CONTAINER}, which allows implementing the behaviour required by the current users of the %^H + Scope::Guard and B::Hooks::EndOfScope users. After showing an early version of this patch to #p5p, the feedback I got was mostly good, but people were wondering if COMPILE_SCOPE_CONTAINER should propagate into string evals, because it might be possible to make it behave differently when a string eval is involved. I tried to come up with a test that demonstrates that, but I failed. I don't think it's possible, but I'd be glad to be proven wrong. I also don't think that propagating into string evals is the behaviour we want. I also can't think of a useful feature that said propagating would allow us to implement.Thread Next