[rt.cpan.org #74289] Don’t make *CORE::foo read-only
authorFather Chrysostomos <sprout@cpan.org>
Tue, 24 Jan 2012 05:45:21 +0000 (21:45 -0800)
committerFather Chrysostomos <sprout@cpan.org>
Tue, 24 Jan 2012 06:11:19 +0000 (22:11 -0800)
commit7e68c38b607a044ee5879e316bb8a7347284ec8e
treef2ec4605547641308b3701628ffc37e9a90d7465
parent6fa2c250307a2b1de4850e25cb3eb81bc16c7244
[rt.cpan.org #74289] Don’t make *CORE::foo read-only

newATTRSUB requires the sub name to be passed to it wrapped up in
a const op.

Commit 8756617677dbd allowed it to accept a GV that way, since
S_maybe_add_coresub (in gv.c) needed to pass it an existing GV not in
the symbol table yet (to simplify code elsewhere).

This had the inadvertent side-effect of making the GV read-only, since
that’s what the check function for const ops does.

Even if we were to call this a feature, it wouldn’t make sense as
implemented, as GVs for non-ampable (&-able) subs like *CORE::chdir
were not being made read-only.

This commit adds a new flag to newATTRSUB, to allow a GV to be passed
as the o parameter, instead of an op.  While this may look as though
it’s undoing the simplification in commit 8756617677dbd by adding
more code, the new code is still conceptually simpler and more
straightforward.

Since newATTRSUB is in the API, I had to add a new _flags variant.
(How did newATTRSUB get into the API to begin with?)

In adding a test, I also discovered that ‘used once’ warnings
were applying to these subs, which is obviously wrong.  Commit
8756617677dbd caused that, too, as it was relying on the side-effect
of newATTRSUB doing a GV lookup.

This fixes that, too, by turning on the multi flag in
S_maybe_add_coresub.
embed.fnc
embed.h
gv.c
op.c
proto.h
t/op/coresubs.t