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

On Sun, Nov 23, 2008 at 10:08 PM, Jonathan Worthington
<[email protected]>wrote:

> 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)
>

Minor detail:
.file does not actually exist, except in PIRC. I do not have a strong
preference for adding it. Pro: it's a bit clearer than .line, as .line
indicates, ehm, the "line" :-) Specifying a filename by .line is a bit
weird. Con: generating 2 directives instead of 1 each time you want to
update the location makes the generated code string a bit longer/more
verbose, which might not be desirable. Anyway, I'm open to anything :-)
(possibly renaming even to .location (or .loc, but that's another well-known
abbreviation)

>
> * .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.
>

I agree.

>
> Thoughts?
>
> Jonathan
>