[perl #45857] [IMCC][RFC] #line vs .line

[Jonathan Worthington]

Patrick R. Michaud wrote:
> Either way works for me -- PCT can generate either without much
> difficulty.  It probably makes more sense to have separate .file
> and .line directives.  In particular, I wouldn't want to be
> repeating the .file annotation information throughout the bytecode!  :-)
>
> Just a reminder that the central issue for PCT and other HLL's
> is that the current #line, setline, setfile, etc. instructions
> are currently intimately tied to lines of PIR source (RT #43269),
> and they probably shouldn't be.
>
> I agree that I don't see a strong need for setting file and
> line number dynamically -- at least not at this stage.
>   
Let me clarify a little. The current ".file" and ".line" directives are 
tied to PIR lines. That's fine, and I'm planning we can keep things that 
way. We could use such a feature now, e.g. in gen_builtins.pir, for 
example. It's useful when you're building PIR from other bits of PIR. 
But I don't expect PCT will be emitting these two directives.

Instead, I expect PCT will emit .annotate. This allows you to emit 
whatever annotations you wish. So you can do file and line annotations, 
but you can also choose to do column too if needed. We can use it to 
stash away the source code for a sub so we can do .perl for subs, or for 
stashing away the compiler version or OS we compiled under for the 
various $?FOO variables. When an exception is thrown, we already capture 
the location it was thrown from, and thus there will be a way to get 
which of these settings were in effect at the point that the exception 
was thrown. As an upshot of this, .annotate is not at all tied to PIR 
lines - the latest annotation under a given key takes precedence. So you 
can emit at the start maybe:

.annotate "file" "foo.pl"
.annotate "compiler" "rakudo-0.1"

And then per line:

.annotate "line" 42

When a new source code line starts.

And yes, I need to get this all into the PIR docs, though the storage 
scheme for all of this is in the bytecode PDD already. But it should 
give us plenty of flexibility.

Sound good?

Thanks,

Jonathan