New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unexpected syntax error #15933
Comments
From @KES777Created by @KES777$ perl -e '$xx ||= 3' $ perl -MO=Concise -e '$xx ||= 3' $ perl -MO=Concise=-debug -e '$xx ||= 3' When I try to walk ops tree in debug mode I got syntax error. Perl Info
|
From @ilmariKES (via RT) <perlbug-followup@perl.org> writes:
This has nothing to do with B::Concise, but the fact that you are using use O 'Concise=-debug'; which O to try to use "B::Concise=-debug" as the name of the backend If you do -MO=Concise,-debug, which is equivalent to use O qw(Concise -debug); it works. This is shown in the B::Concise synopsis: perl -MO=Concise[,OPTIONS] foo.pl Note there's a comma before OPTIONS, not an equal sign. - ilmari -- |
The RT System itself - Status changed from 'new' to 'open' |
From @KES777ah, comma. Thank you. is it possible/reasonable to improve error message here? 26.03.2017, 15:54, "Dagfinn Ilmari Mannsåker via RT" <perlbug-followup@perl.org>:
|
From @KES777It seems that is possible through $^P variable. We should setup flag: x100 but perlrun do not explain how to setup this variable through command line. 26.03.2017, 16:16, "KES" <kes-kes@yandex.ru>:
|
From @tonycozOn Sun, 26 Mar 2017 06:26:14 -0700, kes-kes@yandex.ru wrote:
I don't think that would be all that useful in this case, since the eval is in O.pm. I tried propagating that the code came from the command-line by prepending: #line 1 "<option text here>" eg. #line 1 "-MO=Concise=-debug" to the code generated for -[Mm] switch, and modifying O.pm to add a similar #line based on caller(), but the parser appears to ignore #line directives in PL_preambleav code. Tony |
From @iabynOn Sun, May 21, 2017 at 10:16:58PM -0700, Tony Cook via RT wrote:
Although in general I kind of like the idea that warnings/dies from within Maybe something like ... at (eval 13: from foo.pl:21) line 7 Not sure what it should for nested evals. Not bother, or show the chain: ... at (eval 13: from eval 15:1 from foo.pl:21) line 7 -- |
From zefram@fysh.orgDave Mitchell wrote:
There are reasonable uses of eval that nest them to unbounded depth. But showing any nesting in the way that you propose would break the -zefram |
From @iabynOn Mon, May 22, 2017 at 07:25:13PM +0100, Zefram wrote:
I'm not envisioning storing anything extra. I would just work back So this seems to be more an aesthetic rather than technical decision.
If someone's changed the filename or line number, then we still use that. -- |
From @cpansproutOn Mon, 22 May 2017 12:48:44 -0700, davem wrote:
I don’t understand how what you are proposing differs significantly from what -- Father Chrysostomos |
From @iabynOn Mon, May 22, 2017 at 01:53:43PM -0700, Father Chrysostomos via RT wrote:
Probably because I didn't understand what $^P does. The difference But if bulk88's deduping-CopFILE work gets finished and merged, then
Well, making something like that the default (but only if its not slow). -- |
From @cpansproutOn Mon, 22 May 2017 23:38:52 -0700, davem wrote:
You do realize, don’t you, that it won’t solve the original problem in the ticket? The syntax error was in -M code, not in an eval (unless it is implemented as an eval; I don’t remember). I once had a patch (probably still in a branch) that added ‘in preamble’ to the message if the line number was 0, precisely to solve this kind of problem, but it caused other problems, in that perl -h would add ‘in preamble’ to its output. I never got around to finishing it. -- Father Chrysostomos |
Migrated from rt.perl.org#131062 (status was 'open')
Searchable as RT131062$
The text was updated successfully, but these errors were encountered: