regen/embed.pl: Split list into two - #24662
Open
khwilliamson wants to merge 3 commits into
Open
Conversation
See Perl#24593 Perl 5.44 added the ability to control much better which symbols Perl exports to modules, and which are hidden. It added a large list of symbols that we continue to export, pending a decision on each one's ultimate disposition. This ensures that we don't break something in the meantime. This and the next commit help inform that decision by splitting that list into two: one of symbols which actually appear on cpan; and one where there is no apparent usage. Items on the actually-used list need to be examined more closely before deciding to stop exporting them. One might think that of course we have to continue to export any such item, but we learned recently in examining the KEY_END and KEY_NULL symbols, that the uses on cpan were of different symbols with the same names. Hence our exported symbols were actually namespace pollutants, and should not be exported. (The cpan uses were for keyboard presses of the 'END' key and the CTRL-@ key (NUL). I grepped a snapshot of metacpan for all the symbols whose status is unresolved in embed.pl. My methodology was to 1) checkout the repository 2) grep files with suffixes .c .h .inc* .xs 3) also run the 'file' command on every file, and grep those whose output indicated it was C language. The change is in two parts. 1) This commit just creates the second table (empty), revises the comments, and sorts the original table (which had gotten slightly out of order) so that I could use the 'comm' comand for the next step. 2) The second commit actually splits the symbols The reason for the two commits is simply to help reviewers (and me) check that I didn't do anything untoward. The next commit should have the same number of insertions as deletions, indicating nothing got added or removed by the commit, without having to verify the nearly 1300 changes individually.
The commit message in the previous commit gives the reason this is being done.
I don't know why this got commented out; using it means further reductions in complexity of an expression.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
See #24593
Perl 5.44 added the ability to control much better which symbols Perl
exports to modules, and which are hidden. It added a large list of
symbols that we continue to export, pending a decision on each one's
ultimate disposition. This ensures that we don't break something in the
meantime.
This and the next commit help inform that decision by splitting that
list into two: one of symbols which actually appear on cpan; and one
where there is no apparent usage. Items on the actually-used list need
to be examined more closely before deciding to stop exporting them. One
might think that of course we have to continue to export any such item,
but we learned recently in examining the KEY_END and KEY_NULL symbols,
that the uses on cpan were of different symbols with the same names.
Hence our exported symbols were actually namespace pollutants, and
should not be exported. (The cpan uses were for keyboard presses of the
'END' key and the CTRL-@ key (NUL).
I grepped a snapshot of metacpan for all the symbols whose status is
unresolved in embed.pl. My methodology was to
1) checkout the repository
2) grep files with suffixes .c .h .inc* .xs
3) also run the 'file' command on every file, and grep those
whose output indicated it was C language.