retain the last file handle even if it's an IO reference #19125
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It's always been possible to extract a reference to the IO SV from
a glob, and use that for I/O, but such use would set PL_last_in_gv
to a temporary GV which would almost immediately be released,
clearing PL_last_in_gv.
This would result in reads from
$.
returning its most recently readvalue (even from another handle) and modification being ignored, while
${^LAST_FH}
would return undef, even though the file handle is stillopen.
To fix this, store the underlying IO object as well as the GV.
Retaining the GV lets errors continue to report the GV name where
possible, while the IO object means
$.
and${^LAST_FH}
can still workif the IO object still exists.
This does not try to fix the problem where localization can leave
PL_last_in_gv (and now PL_last_in_io) pointing at a SV that has been
destroyed, the original changes that introduced PL_last_in_gv didn't
keep a reference count for the GV, since this would prevent the file
being close automatically when the reference to to the glob went out
of scope.
Fixes #1420