Klaas-Jan Stol via RT wrote:
On Thu Dec 13 04:35:13 2007, pmichaud wrote:
On Sat Sep 29 08:57:28 2007, kjs wrote:
A few months ago, the "#line" directive was implemented.
I'm wondering what the reason was why it looks like a comment (as #
will
start a comment).
Is there any reason to not replace this by ".line"? A directive
typically
tells the assembler/compiler something, and in this case it updates
the line
number.
As this gets addressed we should also address the handling of the
'setline' opcode (RT #43269).
Pm
.line directive is implemented per r33084. #line still works.
I'm not sure what Pm meant by addressing the handling of 'setline'
opcode, so leaving this ticket open.
I'm planning to work on bytecode annotations Real Soon Now...my thoughts
on these issues are:
* I think .line and .file will remain for setting the PIR-level line and
file (#line and #file maybe too, or we could deprecate those)
* .annotate "key" value / .annotate "key" "value" will be added for
setting annotations, which will form high level language debug info
(.line and .file may be converted to also store data using the new
annotations segment rather than keeping a separate PIR debug segment in
the future; not sure how soon that will happen, will leave the current
debug seg intact for now though)
* setline and setfile opcodes can probably go away; I can't think of a
use case where we'd want to set these dynamically, since we know the
line number/file number/column/whatever else we wish to store at compile
time. Doing an op dispatch rather than making an annotation we can look
up only when we need it seems odd to me.
Thoughts?
Jonathan
