Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
B::Utils(3)	      User Contributed Perl Documentation	   B::Utils(3)

       B::Utils	- Helper functions for op tree manipulation

       version 0.27

       To install this module, run the following commands:

	   perl	Makefile.PL
	   make	test
	   make	install

	 use B::Utils;

	   Returns the name of the op, even if it is currently optimized to
	   null.  This helps you understand the	structure of the op tree.

	   Returns an array of all this	op's non-null children,	in order.

	   Returns the parent node in the op tree, if possible.	Currently
	   "possible" means "if	the tree has already been optimized"; that is,
	   if we're during a "CHECK" block. (and hence,	if we have valid
	   "next" pointers.)

	   In the future, it may be possible to	search for the parent before
	   we have the "next" pointers in place, but it'll take	me a while to
	   figure out how to do	that.

	   Warning: Since 5.21.2 B comes with its own version of B::OP::parent
	   which returns either	B::NULL	or the real parent when	ccflags
	   contains -DPERL_OP_PARENT.  In this case rather use $op->_parent.

	   Returns all parents of this node, recursively. The list is ordered
	   from	younger/closer parents to older/farther	parents.

	   Returns all children	of this	node, recursively. The list is

	   Returns all younger siblings	of this	node. The list is ordered from
	   younger/closer siblings to older/farther siblings.

	   Like	" $op->next ", but not quite.

	   Returns a nice stringification of an	opcode.

	   From	the op tree it is called on, "as_opgrep_pattern()" generates a
	   data	structure suitable for use as a	condition pattern for the
	   "opgrep()" function described below in detail.  Beware: When	using
	   such	generated patterns, there may be false positives: The pattern
	   will	most likely not	match only the op tree it was generated	from
	   since by default, not all properties	of the op are reproduced.

	   You can control which properties of the op to include in the
	   pattern by passing named arguments. The default behaviour is	as if
	   you passed in the following options:

	     my	$pattern = $op->as_opgrep_pattern(
	       attributes	   => [qw(name flags)],
	       max_recursion_depth => undef,

	   So obviously, you can set "max_recursion_depth" to a	number to
	   limit the maximum depth of recursion	into the op tree. Setting it
	   to 0	will limit the dump to the current op.

	   "attributes"	is a list of attributes	to include in the produced
	   pattern. The	attributes that	can be checked against in this way

	     name targ type seq	flags private pmflags pmpermflags.

	   Returns a hash of all of the	starting ops or	root ops of optrees,
	   keyed to subroutine name; the optree	for main program is simply
	   keyed to "__MAIN__".

	   Note: Certain "dangerous" stashes are not scanned for subroutines:
	   the list of such stashes can	be found in @B::Utils::bad_stashes.
	   Feel	free to	examine	and/or modify this to suit your	needs. The
	   intention is	that a simple program which uses no modules other than
	   "B" and "B::Utils" would show no addition symbols.

	   This	does not return	the details of ops in anonymous	subroutines
	   compiled at compile time. For instance, given

	       $a = sub	{ ... };

	   the subroutine will not appear in the hash. This is just as well,
	   since they're anonymous... If you want to get at them, use...

	   This	returns	an array of hash references. Each element has the keys
	   "start" and "root". These are the starting and root ops of all of
	   the anonymous subroutines in	the program.

	   If PL_sub_generation	has changed or you have	some other reason to
	   want	to force the re-examination of the optrees, everywhere,	call
	   this	function.

       "walkoptree_simple($op, \&callback, [$data])"
	   The "B" module provides various functions to	walk the op tree, but
	   they're all rather difficult	to use,	requiring you to inject
	   methods into	the "B::OP" class. This	is a very simple op tree
	   walker with more expected semantics.

	   All the "walk" functions set	$B::Utils::file, $B::Utils::line, and
	   $B::Utils::sub to the appropriate values of file, line number, and
	   sub name in the program being examined.

       "walkoptree_filtered($op, \&filter, \&callback, [$data])"
	   This	is much	the same as "walkoptree_simple", but will only call
	   the callback	if the "filter"	returns	true. The "filter" is passed
	   the op in question as a parameter; the "opgrep" function is
	   fantastic for building your own filters.

       "walkallops_simple(\&callback, [$data])"
	   This	combines "walkoptree_simple" with "all_roots" and "anon_subs"
	   to examine every op in the program. $B::Utils::sub is set to	the
	   subroutine name if you're in	a subroutine, "__MAIN__" if you're in
	   the main program and	"__ANON__" if you're in	an anonymous

       "walkallops_filtered(\&filter, \&callback, [$data])"
	   Same	as above, but filtered.

       "opgrep(\%conditions, @ops)"
	   Returns the ops which meet the given	conditions. The	conditions
	   should be specified like this:

	       @barewords = opgrep(
				   { name => "const", private => OPpCONST_BARE },

	   where the first argument to "opgrep()" is the condition to be
	   matched against the op structure. We'll henceforth refer to it as
	   an op-pattern.

	   You can specify alternation by giving an arrayref of	values:

	       @svs = opgrep ( { name => ["padsv", "gvsv"] }, @ops)

	   And you can specify inversion by making the first element of	the
	   arrayref a "!". (Hint: if you want to say "anything", say "not
	   nothing": "["!"]")

	   You may also	specify	the conditions to be matched in	nearby ops as
	   nested patterns.

		   sub { opgrep( {name => "exec",
				  next => {
					    name    => "nextstate",
					    sibling => { name => [qw(! exit warn die)] }
				 }, @_)},
		   sub {
			 carp("Statement unlikely to be	reached");
			 carp("\t(Maybe	you meant system() when	you said exec()?)\n");

	   Get that?

	   Here	are the	things that can	be tested in this way:

		   name	targ type seq flags private pmflags pmpermflags
		   first other last sibling next pmreplroot pmreplstart	pmnext

	   Additionally, you can use the "kids"	keyword	with an	array
	   reference to	match the result of a call to "$op->kids()". An
	   example use is given	in the documentation for "op_or" below.

	   For debugging, you can have many properties of an op	that is
	   currently being matched against a given condition dumped to STDERR
	   by specifying "dump =" 1> in	the condition's	hash reference.

	   If you match	a complex condition against an op tree,	you may	want
	   to extract a	specific piece of information from the tree if the
	   condition matches.  This normally entails manually walking the tree
	   a second time down to the op	you wish to extract, investigate or
	   modify. Since this is tedious duplication of	code and information,
	   you can specify a special property in the pattern of	the op you
	   wish	to extract to capture the sub-op of interest. Example:

	     my	($result) = opgrep(
	       { name => "exec",
		 next => { name	   => "nextstate",
			   sibling => {	name =>	[qw(! exit warn	die)]
					capture	=> "notreached",

	     if	($result) {
	       my $name	= $result->{notreached}->name; # result	is *not* the root op
	       carp("Statement unlikely	to be reached (op name:	$name)");
	       carp("\t(Maybe you meant	system() when you said exec()?)\n");

	   While the above is a	terribly contrived example, consider the win
	   for a deeply	nested pattern or worse	yet, a pattern with many
	   disjunctions.  If a "capture" property is found anywhere in the op
	   pattern, "opgrep()" returns an unblessed hash reference on success
	   instead of the tested op. You can tell them apart using
	   Scalar::Util's "blessed()". That hash reference contains all
	   captured ops	plus the tested	root up	as the hash entry
	   "$result->{op}". Note that you cannot use this feature with
	   "walkoptree_filtered" since that function was specifically
	   documented to pass the tested op itself to the callback.

	   You cannot capture disjunctions, but	that doesn't really make sense

       "opgrep(	\@conditions, @ops )"
	   Same	as above, except that you don't	have to	chain the conditions
	   yourself.  If you pass an array-ref,	opgrep will chain the
	   conditions for you using "next".  The conditions can	either be
	   strings (taken as op-names),	or hash-refs, with the same testable
	   conditions as given above.

       "op_or( @conditions )"
	   Unlike the chaining of conditions done by "opgrep" itself if	there
	   are multiple	conditions, this function creates a disjunction
	   ("$cond1 || $cond2 || ...") of the conditions and returns a
	   structure (hash reference) that can be passed to opgrep as a	single


	     my	$sub_structure = {
	       name => 'helem',
	       first =>	{ name => 'rv2hv', },
	       'last' => { name	=> 'const', },

	     my	@ops = opgrep( {
		 name => 'leavesub',
		 first => {
		   name	=> 'lineseq',
		   kids	=> [,
		     { name => 'nextstate', },
			 name => 'return',
			 first => { name => 'pushmark' },
			 last => $sub_structure,
	     },	$op_obj	);

	   This	example	matches	the code in a typical simplest-possible
	   accessor method (albeit not down to the last	bit):

	     sub get_foo { $_[0]->{foo}	}

	   But by adding an alternation	we can also match optional op layers.
	   In this case, we optionally match a return statement, so the
	   following implementation is also recognized:

	     sub get_foo { return $_[0]->{foo} }

	   Essentially,	this is	syntactic sugar	for the	following structure
	   recognized by "opgrep()":

	     { disjunction => [@conditions] }

	   Warn	and die, respectively, from the	perspective of the position of
	   the op in the program. Sounds complicated, but it's exactly the
	   kind	of error reporting you expect when you're grovelling through
	   an op tree.

       None by default.

       This modules uses ExtUtils::Depends to export some useful functions for
       XS modules to use.  To use those, include in your Makefile.PL:

	 my $pkg = ExtUtils::Depends->new("Your::XSModule", "B::Utils");
	   ... # your normal makefile flags

       Your XS module can now include BUtils.h and BUtils_op.h.	 To see
       document	for the	functions provided, use:

	 perldoc -m B::Utils::Install::BUtils.h
	 perldoc -m B::Utils::Install::BUtils_op.h

       Originally written by Simon Cozens, "" Maintained by
       Joshua ben Jore,	""

       Contributions from Mattia Barbon, Jim Cromie, Steffen Mueller, and
       Chia-liang Kao, Alexandr	Ciornii, Reini Urban.

       This module is free software; you can redistribute it and/or modify it
       under the same terms as Perl itself.

       B, B::Generate.

perl v5.32.1			  2015-07-22			   B::Utils(3)


Want to link to this manual page? Use this URL:

home | help