Perl restores debugger access to enclosing lexical names

A debugger can stop in a closure and still fail to evaluate a name that belongs to its enclosing scope. That failure does not necessarily mean the variable is absent from the program. It can mean the interpreter has not retained the contextual information needed to compile a new expression at the debugger prompt.

Perl 5.39.4 repairs such a case. The release history dates the snapshot to October 25. Its release notes say enclosing lexical names in a lexical subroutine or closure were not visible to string evaluation called from package DB. The regression began in Perl 5.18 during an attempt to stop subroutines retaining a reference to their outer scope.

I regard debugger accuracy as part of a language's practical usability. Perl's compact expressions already ask the reader to understand several interacting rules. A debugger that loses legitimate lexical context makes it harder to distinguish a program mistake from a limitation in the inspection machinery.

DB evaluation deliberately looks outside DB

The version's function reference documents special behavior for string eval inside a subroutine defined in package DB. It does not use the usual lexical surroundings of that debugger subroutine. Instead, it uses the scope of the first non-DB code that called it.

That exception is what makes expression evaluation useful during debugging. A user inspecting stopped application code wants names from that code's context. Resolving only names in the debugger implementation would answer a different question. The package boundary tells the interpreter which context the debugger is asking to inspect.

Ordinary string evaluation and this debugger case therefore cannot be explained solely by the package containing the eval statement. The documentation explicitly supplies a different lexical-context rule for DB. The October repair restores information that this rule needs when the stopped code is a lexical subroutine or closure.

The release does not say that arbitrary application evaluation should gain access to every caller's lexical variables. The documented exception has a specific debugger context. Generalizing the fix into unrestricted dynamic lexical lookup would misstate both the original behavior and the repair.

Retaining outer context has a cost

The release note identifies the historical tension directly. The earlier interpreter change tried to avoid having subroutines retain a reference to their outer scope. That goal concerns lifetime and retained implementation state. The debugger, however, may need more lexical-name context than the subroutine's ordinary execution path requires.

A closure's existing operations were compiled before the debugger expression was entered. The debugger's string must be compiled later against the stopped context. Information sufficient to execute the already compiled body is not automatically sufficient to resolve every name in a newly supplied expression.

This explains why a storage-oriented optimization can create a debugging regression without announcing a new scoping rule for application source. The interpreter can still run the original operation while the debugger fails to reconstruct its surrounding name environment. The release notes identify the broken special behavior and the change that originally caused it.

The fix also resolves a TODO test for B::Deparse, according to the notes. That is a useful indication that retained lexical information affects more than an interactive prompt. The published description does not claim to repair every deparsing limitation, so that incidental test result should stay attached to this particular change.

Debugging is an interpreter facility

The debugger internals reference describes compile-time and runtime hooks enabled by perl -d. Running with these hooks supplies additional source and execution information to make inspection possible. Debugger code uses that information through the documented interpreter interfaces.

For example, arrays associated with compiled source files hold their lines, and corresponding hashes describe breakpoints and actions by line number. Numeric interpretation of the stored source-line values indicates whether a line can hold a breakpoint. The representation combines human-readable source with information the interpreter uses during execution.

Subroutine calls can also pass through DB::sub, with $DB::sub identifying the target. The reference distinguishes named targets from subroutines identified by references. These hooks explain why preserving debugger behavior requires coordination with the interpreter's ordinary call machinery.

The October release includes another debugger-related repair involving the source-line arrays. Removing a dbstate operation must not clear an integer flag from the corresponding stored line. That is separate from lexical lookup, but it illustrates how debugger correctness depends on implementation metadata that does not appear in the application source.

Inspection has documented limits

The function reference gives another example of special DB handling in caller. With an argument and list context, calls from DB populate @DB::args with the inspected subroutine's arguments. The same documentation calls that result best effort and warns about optimized call frames and argument mutation.

Restoring lexical-name evaluation does not remove those separate limits. A debugger can correctly resolve a surrounding name while another inspection operation still has the qualifications documented for it. Precise expectations depend on which interpreter facility supplies the information.

I find the release's narrow description useful because it identifies what a maintainer can now rely on again. String evaluation from DB recovers the enclosing lexical names affected by the regression. The surrounding debugger hooks retain their own contracts, including the limits on reconstructing argument and frame information.