[% setvar title Emit warnings and errors based on unoptimized code %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <table bgcolor="red"><tr><td><font color="white"> Note: these documents may be out of date. Do <b>not</b> use as reference!</font></tr></td></table>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='TITLE'></a><h1>TITLE</h1>
<p>Emit warnings and errors based on unoptimized code</p>
<a name='VERSION'></a><h1>VERSION</h1>
<pre>  Maintainer: Nathan Torkington &lt;<a href='mailto:gnat@frii.com'>gnat@frii.com</a>&gt;
  Date: 12 Sep 2000
  Last Modified: 15 Sep 2000
  Mailing List: <a href='mailto:perl6-internals@perl.org'>perl6-internals@perl.org</a>
  Number: 214
  Version: 2
  Status: Developing</pre>
<a name='ABSTRACT'></a><h1>ABSTRACT</h1>
<p>When code triggers warnings or errors, those warnings
or errors should report the code that caused them.
If the code has been rewritten or altered by the optimizer,
the unoptimized code should be be what's cited in the
text of the warning or error message.</p>
<a name='CHANGES'></a><h1>CHANGES</h1>
<pre> * Added &quot;except where it's impossible&quot; clause</pre>
<a name='DESCRIPTION'></a><h1>DESCRIPTION</h1>
<p>In perl5 it's easy to get warnings about code you
didn't write (this is from perl5.6.0, but similar problems
with &quot;use&quot; turning into a &quot;BEGIN&quot; block have been present
in Perl for a long time):</p>
<pre>  print &quot;what's that, $perl?&quot;;

  Use of uninitialized value in concatenation (.) at -e line 1.</pre>
<p>Perl has rewritten the double-quoted string as</p>
<pre>  &quot;what's that, &quot; . $perl . &quot;?&quot;</pre>
<p>and when the uninitialized value warning is generated,
Perl reports it as coming from the concatenation operation.</p>
<p>This is misleading and confuses users.  When Perl needs to report
errors or warnings, it should describe the code the programmer wrote,
regardless of how that's been translated within Perl.</p>
<p>The only exception to this is when an optimization results in the
irrecoverable loss of this information.  Such optimizations should
be weighed on their individual merits, taking into account the
potential confusion they could cause.  Where possible, warnings and
errors should report useful location information to the user.</p>
<a name='IMPLEMENTATION'></a><h1>IMPLEMENTATION</h1>
<p>Each op could keep track of the name of the construct that it came
from.  Instead of reporting errors in terms of ops, report errors in
terms of source-level constructs.</p>
<p>This may bloat the op tree/bytecode.  There could be an option to
strip these debugging symbols from the bytecode, much as strip(1)
works on Unix, if this overhead is not welcome.</p>
<p>perl526 will not be able to successfully translate any code that
relies on parsing warnings or error messages.</p>
<a name='REFERENCES'></a><h1>REFERENCES</h1>
<p>perldiag manpage for Perl's error messages and warnings</p>
</div>