[erlang-patches] Print column numbers when compiling

Henrik Nord <>
Mon Sep 10 10:25:50 CEST 2012

Thank you!
I have refetched this
On 09/09/2012 12:52 PM, Anthony Ramine wrote:
> Hi,
> I've rebased it against the latest maint branch. Please refetch.
> On Wed, Sep 5, 2012 at 10:50 AM, Henrik Nord <> wrote:
>> I would like you to rebase this on R15B02 after the release.
>> /Henrik
>> On 09/02/2012 08:26 PM, Anthony Ramine wrote:
>>> Hi,
>>> Again, see responses inlined; please refetch.
>>> Regards.
>>> --
>>> Anthony Ramine
>>> Le 28 août 2012 à 15:28, Lukas Larsson a écrit :
>>>> Hello,
>>>> See responses inlined.
>>>> Lukas
>>>> On 24/08/12 12:22, Anthony Ramine wrote:
>>>>> Most OTP (at least erl_lint, erl_parse and syntax_tools) already knows
>>>>> that locations can be a line or a line and a column; furthermore it is said
>>>>> in erl_parse itself that one should always use get_line/1 and set_line/3
>>>>> instead of depending on having an integer there.
>>>> It does indeed say so inside the code of erl_parse. But all of the
>>>> visible documentation (here[1] and here[2]) say that it is an integer. So if
>>>> you have only read the documentation (which I assume most people only have)
>>>> you would assume that it is an integer. That documentation has to be updated
>>>> so that LINE can be either an integer() or a tuple(integer(),integer()), and
>>>> a reference to use erl_parse:set/get_attribute to manipulate it safely.
>>>> The compiler should also be updated to use these API's, this includes
>>>> the convention that a line number of -1 is used to say that something is
>>>> compiler generated. To make sure that all uses of the non-api is eliminated,
>>>> it might be a good idea to declare erl_scan:line as -opaque and let dialyzer
>>>> search through the otp code for errors.
>>>> [1]: http://www.erlang.org/doc/apps/erts/absform.html
>>>> [2]: http://www.erlang.org/doc/man/erl_scan.html#type-line
>>> I replaced LINE by LOC in the first documentation you point to and I've
>>> patched various type specs in erl_scan and erl_parse so they both use
>>> location().
>>> With regard to negative line numbers, it should be noted that
>>> user-supplied -file attributes have their line numbers negated whereas as
>>> you said in other modules like erl_lint and v3_core, compile-generated nodes
>>> are the ones which lines are negated. Shouldn't the opposite be done in
>>> epp's -file attributes handling?
>>>>> If it is really that heavy of a change, why do we have
>>>>> erl_scan:set_attribute/3 and erl_scan:attributes_info/{1,2}? They obviously
>>>>> were coded to mitigate these issues.
>>>> We have indeed been working on getting this to work before, but the
>>>> effort was left as you see it now because there were a number of issues
>>>> which needed solving and more important things got in the way. The reason
>>>> why I say it is a heavy change is that we want to feel that a good effort
>>>> has been made to make sure that all error and warning column numbers point
>>>> to the correct position.
>>> I've already added a 'file' item to these functions to improve the code
>>> populating every node with the file from the -file attributes of the module
>>> declaration in erl_lint; maybe another 'generated' item should be added to
>>> replace the multiple neg_line and abs_line functions there are in some
>>> compile-related modules?
>>>>> Any parse transform that break because of this change will break
>>>>> because it does AST manipulation wrong and their users will just have to not
>>>>> use the "column" option for it to continue to work.
>>>> Strictly speaking parse transform is also an experimental/undocumented
>>>> feature of Erlang/OTP. But unfortunately a lot of people seem to use them,
>>>> so we have to take some backwards compatibility into consideration. The
>>>> closest thing to a documentation is the example found here
>>>> lib/stdlib/example/erl_id_trans.erl, and that does not deal with line
>>>> numbers at all.
>>>> We really really have to be sure that the fun2ms and qlc parse
>>>> transforms work.
>>> I've read through the code of various parse transforms this week and they
>>> don't seem to make anything related to the transformed nodes' locations.
>>> Most OTP-provided parse transforms are covered in the test suites I patched.
>>> _______________________________________________
>>> erlang-patches mailing list
>>> http://erlang.org/mailman/listinfo/erlang-patches
>> --
>> /Henrik Nord Erlang/OTP

/Henrik Nord Erlang/OTP

More information about the erlang-patches mailing list