Untraceable warning: "Warning: Use of "require" without parenthesesis ambiguous at (eval 23) line 1.

[Julian Mehnle]

Hi all,

I'm having problems tracing a

Warning: Use of "require" without parentheses is ambiguous at (eval 23)line 1.

warning. It occurs in a larger program that has multiple "require"s and
"eval"s, and the line numbers aren't helpful at all.

I have tried inserting "use diagnostics qw(-traceonly -warntrace);" into
the program, but I still don't get a stack trace, just the exact same
warning message.

What can I do to get a stack trace?

TIA,
Julian Mehnle.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEaoBMwL7PKlBZWjsRAmkJAKD7eikG+W1QkcT8Z/cX093PU5OSiwCgp5nH
dJm4Sq9rdzd/k0Or+g5xdV4=
=ltX1
-----END PGP SIGNATURE-----

 

[Julian Mehnle]

I have tried inserting "use diagnostics qw(-traceonly -warntrace);" into
the program, but I still don't get a stack trace, just the exact same
warning message.

Sorry for replying to myself, but a minor correction is in order: it's
"-trace", not "-traceonly" (the latter is described in `perldoc
diagnostics`, but only the former actually works).

Julian.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEaoElwL7PKlBZWjsRAugBAKCzGnmVcsz38UmZEBYD3uyRPiKDwACfdfP0
BkK+Hl8a66ar5b877CmziII=
=HTp7
-----END PGP SIGNATURE-----

 

[Julian Mehnle]

Sorry for replying to myself, but a minor correction is in order: it's
"-trace", not "-traceonly" (the latter is described in `perldoc
diagnostics`, but only the former actually works).

Now I guess I've almost used up my good karma for this year, having to
make yet another amendment to my posting. I did NOT mean to say that
"use diagnostics qw(-trace -warntrace);" "actually works" to give me a
stack trace (sorry for the ambiguous wording). It doesn't -- it just
doesn't blow in my face as "qw(-traceonly)" (as documented in the
diagnostics module) does.

So how can I get a stack trace to debug this 'Use of "require" without
parentheses is ambiguous' warning?

Julian.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEaoKUwL7PKlBZWjsRAoR0AKCBz9AnF05xjEcPhVl97xbl8v+a1wCgj3wH
fdrD3dRePldJ0JmIV9A5Sz8=
=w3we
-----END PGP SIGNATURE-----

 

[Ben Morrow]

Now I guess I've almost used up my good karma for this year, having to
make yet another amendment to my posting. I did NOT mean to say that
"use diagnostics qw(-trace -warntrace);" "actually works" to give me a
stack trace (sorry for the ambiguous wording). It doesn't -- it just
doesn't blow in my face as "qw(-traceonly)" (as documented in the
diagnostics module) does.

So how can I get a stack trace to debug this 'Use of "require" without
parentheses is ambiguous' warning?

I get

~% perl -v

This is perl, v5.8.7 built for i686-linux
....

~% perl -Mdiagnostics=-trace,-warntrace -le'sub foo{warn "foo"; die} foo'
foo at -e line 1.
at -e line 1
main::foo() called at -e line 1

Uncaught exception from user code:
Died at -e line 1.
at -e line 1
main::foo() called at -e line 1

However, I also get

~% perl -Mdiagnostics=-w,-t -le'sub foo{require +5} foo'
Warning: Use of "require" without parentheses is ambiguous at -e line 1.
at -e line 1

: the warning is issued at compile time, so there is no call to &foo in
the stack trace, indeed no stack at all yet. The file/line no should be
right, though.

Ben

 

[xhoster]

Hi all,

I'm having problems tracing a

Warning: Use of "require" without parentheses is ambiguous at
(eval)
line 1.

warning. It occurs in a larger program that has multiple "require"s and
"eval"s, and the line numbers aren't helpful at all.

I have tried inserting "use diagnostics qw(-traceonly -warntrace);"

Those appear to only trace run-time warnings, not compiler warnings.
(Even if the thing being compiled is in an eval.)

What can I do to get a stack trace?

Maybe:

use Carp qw(cluck);
$SIG{__WARN__}=sub {cluck
$_[0]};


Xho

 

[Julian Mehnle]

~% perl -Mdiagnostics=-w,-t -le'sub foo{require +5} foo'
Warning: Use of "require" without parentheses is ambiguous at -e line 1.
at -e line 1

: the warning is issued at compile time, so there is no call to &foo in
the stack trace, indeed no stack at all yet.

Makes sense. Too bad.

The file/line no should be right, though.

Well, "at (eval) line 1" isn't very helpful because there are lots of
one-line "eval"s in my project, and "(eval 23)" presumably means the 23rd
"eval" encountered, but which one is that?

I'm at a total loss as of how to crack this nut, save from running it
through `perl -d`, which isn't really viable given that the project's size
is non-trivial and I haven't found out yet how to reproduce the bug. (Oh,
and it's a CGI application.)

Julian.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEaxe5wL7PKlBZWjsRAgCEAKC8EtHIw/aXVXw1QDymtEm9rWOKIACdE5MR
ePYuXN+ptgHKIeYX73TdAsc=
=2Lfe
-----END PGP SIGNATURE-----

 

[Julian Mehnle]

What can I do to get a stack trace?

Maybe:

use Carp qw(cluck);
$SIG{__WARN__}=sub {cluck $_[0]};

I tried

use Carp qw(verbose);
BEGIN { $SIG{__WARN__} = sub { Carp::cluck(@_) } }

...but it didn't help. The WARN handler wasn't invoked by the compiler
warning.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEaxhnwL7PKlBZWjsRAnM6AKCCd+NdEOABt6jYXQPI4iHn5irH6ACgqAET
pn2XLpugJY8zx7M/A3SHC1M=
=SPaW
-----END PGP SIGNATURE-----

 

[David Squire]

Makes sense. Too bad.


Well, "at (eval) line 1" isn't very helpful because there are lots of
one-line "eval"s in my project, and "(eval 23)" presumably means the 23rd
"eval" encountered, but which one is that?

I'm at a total loss as of how to crack this nut, save from running it
through `perl -d`, which isn't really viable given that the project's size
is non-trivial and I haven't found out yet how to reproduce the bug. (Oh,
and it's a CGI application.)

Perhaps just at the command line, grep for require, with a view lines of
context either side so that you can see if it's in an eval, and look for
ones that look potentially ambiguous?

DS

 

[Ben Morrow]

-=-=-=-=-=-



Makes sense. Too bad.


Well, "at (eval) line 1" isn't very helpful because there are lots of
one-line "eval"s in my project, and "(eval 23)" presumably means the 23rd
"eval" encountered, but which one is that?

An eval is different; here, there *is* a runtime stack and Perl should
show it you. I get

~% perl -Mdiagnostics=-w,-t -e'1;' -e'sub foo {eval "require +5;"} foo'
Warning: Use of "require" without parentheses is ambiguous at (eval 2) line 1.
at (eval 2) line 1
eval 'require+5;' called at -e line 2
main::foo() called at -e line 2

which seems to me to contain all required information; do you get
something different?

I'm at a total loss as of how to crack this nut, save from running it
through `perl -d`, which isn't really viable given that the project's size
is non-trivial and I haven't found out yet how to reproduce the bug. (Oh,
and it's a CGI application.)

I have to say, I can't see how you could get that warning without doing
something pretty weird. The warning is issued for require followed
immediately by a binary operator; you could try grepping for
'require[[:space:]]*\+' and so on...

Ben

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Julian Mehnle

Well, "at (eval) line 1" isn't very helpful because there are lots of
one-line "eval"s in my project, and "(eval 23)" presumably means the 23rd=

"eval" encountered, but which one is that?

I'm at a total loss as of how to crack this nut, save from running it
through `perl -d`, which isn't really viable given that the project's siz=
e
is non-trivial and I haven't found out yet how to reproduce the bug. (Oh=
,
and it's a CGI application.)

What has perl -d to do with the project size? You should get all the
info from debugger.

Hope this helps,
Ilya

 

[Julian Mehnle]

What has perl -d to do with the project size? You should get all the
info from debugger.

If I don't know how to reproduce the bug, then the number of situations I
have to test with the debugger grows roughly exponentially with code size.

A few minutes ago I luckily found the bug by accident (I was embedding
RFC3066-style language tags, e.g. "en", in class names that would then be
require'd, which would obviously fail if the lang tag had a hyphen in it,
e.g. "en-us"). But the question remains how that bug could have been
traced back from the warning message given by Perl.

Perhaps Perl should be giving the _real_ line number in the _real_ source
file in such cases, as the debugger does?

I guess I'm going to file wish to the Perl developers on this one.

Thanks for everyone's ideas!

Julian.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEa0zAwL7PKlBZWjsRAhM+AJ0fG5rI5R19LZZ/UXb7Lf1mSgNVlQCg+8E1
TuEDbwwhS6d5/U5LQ1BP5+s=
=58TJ
-----END PGP SIGNATURE-----

 

[Julian Mehnle]

An eval is different; here, there *is* a runtime stack and Perl should
show it you. I get

~% perl -Mdiagnostics=-w,-t -e'1;' -e'sub foo {eval "require +5;"} foo'
Warning: Use of "require" without parentheses is ambiguous at (eval 2) line 1.
at (eval 2) line 1
eval 'require+5;' called at -e line 2
main::foo() called at -e line 2

which seems to me to contain all required information; do you get
something different?

No, that's what I get, too, if I enter in bash what you wrote above.
However I could not call the application that way because it is a CGI. As
I wrote, I tried saying "use diagnostics qw(-t -w)" in the main CGI
script, but it still didn't give me a stack trace. I still don't
understand why not, but that's what happened anyway.

I have to say, I can't see how you could get that warning without doing
something pretty weird. The warning is issued for require followed
immediately by a binary operator; you could try grepping for
'require[[:space:]]*\+' and so on...

As I wrote in another posting a minute ago, I did something pretty weird
alright. In effect I was doing eval("require AppName::L10N::$lang"), with
$lang eq 'en-us'. Hard to spot, but pretty obvious now that I found it.
/me slaps forehead.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEa06/wL7PKlBZWjsRAhWWAJ0eXhcEukmXHk3AUQAFTWDZw09BcACZAWmD
jONzxt/CgZccgAs6McpzM0M=
=RGhI
-----END PGP SIGNATURE-----

 

[xhoster]

What can I do to get a stack trace?

=20
Maybe:
=20
use Carp qw(cluck);
$SIG{__WARN__}=3Dsub {cluck $_[0]};

I tried

use Carp qw(verbose);
BEGIN { $SIG{__WARN__} =3D sub { Carp::cluck(@_) } }

=2E..but it didn't help. The WARN handler wasn't invoked by the
compiler=

warning.

For me it is.

use Carp qw(cluck);
use Data:umper;

$SIG{__WARN__}=sub {cluck $_[0]};

foreach ( 1..10) {
#eval "print rand + 5" ;
eval "require +5" ;
};
__END__
Warning: Use of "require" without parentheses is ambiguous at (eval 1) line
1.
at foo.pl line 4
main::__ANON__('Warning: Use of "require" without parentheses is
ambiguous at...') called at (eval 1) line 1 eval 'require^@+5
;' called at foo.pl line 8
Warning: Use of "require" without parentheses is ambiguous at (eval 2) line
1.
at foo.pl line 4
main::__ANON__('Warning: Use of "require" without parentheses is
ambiguous at...') called at (eval 2) line 1 eval 'require^@+5
;' called at foo.pl line 8


Xho

 

[xhoster]

Makes sense. Too bad.


Well, "at (eval) line 1" isn't very helpful because there are lots of
one-line "eval"s in my project, and "(eval 23)" presumably means the
23rd=

"eval" encountered, but which one is that?

If nothing better comes along, add some:

eval 'warn "eval warning number 1"';

to your code. They will report both the embedded string, and the (eval
23), so you can use them as landmarks to navigate.


Xho

 

[Brian McCauley]

Makes sense. Too bad.


Well, "at (eval) line 1" isn't very helpful because there are lots of
one-line "eval"s in my project, and "(eval 23)" presumably means the 23rd
"eval" encountered, but which one is that?

You can change the default "(eval n)" to something more meaning full by
changing...

eval $cmd;

....to...

eval qq(#line 1 "(eval something meaningful)"\n$cmd);

Obviously if the eval is visited many times in your code you would what
to make "something meaningful" contain something that gives you
context.

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Julian Mehnle

If I don't know how to reproduce the bug, then the number of situations I=

have to test with the debugger grows roughly exponentially with code size=

Apparently, you knew how to reproduce the bug when you posted.

Perhaps Perl should be giving the _real_ line number in the _real_ source=
file in such cases, as the debugger does?

Perhaps you should have *asked* Perl to do this, as, e.g., the
debugger does? Perhaps, look for debugging flags variable?

Hope this helps,
Ilya

 

[Julian Mehnle]

You can change the default "(eval n)" to something more meaning full by
changing...

eval $cmd;

...to...

eval qq(#line 1 "(eval something meaningful)"\n$cmd);

Obviously if the eval is visited many times in your code you would what
to make "something meaningful" contain something that gives you
context.

Wow, that sure is a helpful technique!

$ perl -Mdiagnostics=-w,-t -e'sub foo {eval "require +5;"} foo'
Warning: Use of "require" without parentheses is ambiguous at (eval 2)
line 1.
at (eval 2) line 1
eval 'require+5;' called at -e line 1
main::foo() called at -e line 1

$ perl -Mdiagnostics=-w,-t -e'sub foo {eval qq(#line 1 "my little
eval"\n require +5} foo'
Warning: Use of "" without parentheses is ambiguous at my little eval
line 1.
at my little eval line 1
eval 'line 1 "my little eval"
require +5;' called at -e line 1
main::foo() called at -e line 1

I didn't know that feature, but now I found it is documented at the very
bottom of `perldoc perlsyn`. Thanks for the hint!

----

But:

$ perl -Mdiagnostics=-w,-t -e'sub foo {eval qq(#line 1 "(my little
eval)"\n require +5} foo'
$

Huh? It seems one cannot use parentheses in line directive filenames, or
Perl suppresses the warnings.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEbFMowL7PKlBZWjsRAgORAKDBcmvrKw8c5v2b4rqZR6addTdHZgCePCnN
AS+kYLgG7UyTZ4V6b1oSqUQ=
=JJEK
-----END PGP SIGNATURE-----

 

[Julian Mehnle]

For me it is.

I believe you. I said that I could reproduce it outside my CGI
application, but not inside. I guess it has something to do with the app
loading CGI::Carp, which probably installs its own WARN handler and throws
the other one away. I'm not sure, though.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEbFPawL7PKlBZWjsRAlk4AJ90XD+VN3lunOz2s8phwUOpvskJ4gCggLLA
w8ZfUe/OLj3jB5NGBOZs1nU=
=BbA4
-----END PGP SIGNATURE-----