[erlang-questions] Dialyzer type/spec info question

[Robert Virding]

Something much naughtier and more basic.

- Make LFE local copies of the relevant dialyzer modules which have been
hacked to be able to handle LFE files as input (with a new --lfe option)
- Run dialyzer using -pa to push the local module directory first so as to
use these special modules instead of the standard ones

This will make it possible to use dialyzer on LFE files and other .erl or
.beam files as well. Maybe with a little more hacking fix have multiple
file types. Of course if dialyzer was to be opened up so that it would use
the filename extension to pick the right versions of the functions Stavros
mentioned then this would be much simpler. Wink, wink, nudge nudge. :-)

This is my plan anyway.

Robert

P.S. Having LFE generate erlang AST has never been an option as it is very
close to core and it would take a lot of effort to go back to erlang which
would then be undone by the erlang compiler.


On 17 November 2014 17:49, José Valim <jose.valim@REDACTED>
wrote:

> Robert, what would a specialized version of dialyzer entail? A fork? A
> specific front-end? Curious. :)
>
> On Monday, November 17, 2014, Robert Virding <rvirding@REDACTED> wrote:
>
>> Ah, so then in principle I can make my own specialised versions of the
>> dialyzer load modules which takes the core which the LFE compiler generates
>> and extracts the core and the type/spec data dialyzer needs. This without
>> any Erlang AST which LFE never generates anyway.
>>
>> Now we are getting somewhere useful. With this we don't really need to be
>> able to store core in the .beam files if we can accept using source files
>> as input.
>>
>> Robert
>>
>>
>> On 17 November 2014 17:32, Stavros Aronis <aronisstav@REDACTED> wrote:
>>
>>> For .erl files, dialyzer calls the compiler with 'to_pp', which stops
>>> the compilation before code is converted to Core, and reads attributes from
>>> there.
>>>
>>> Judging from v3_core, line 170 the two representations should be
>>> compatible.
>>>
>>> /Stavros
>>>
>>> On Mon, Nov 17, 2014 at 5:11 PM, Robert Virding <rvirding@REDACTED>
>>> wrote:
>>>
>>>> From where does it get it if I have .erl files as input? From the AST
>>>> as well? Do you know if there is any difference in the data itself between
>>>> the AST and core? I am guessing not but want to check. If there is no
>>>> difference then the info could be gotten from Core. This would make it
>>>> easier to use dialyzer together with LFE.
>>>>
>>>> Robert
>>>>
>>>>
>>>> On 17 November 2014 17:03, Stavros Aronis <aronisstav@REDACTED> wrote:
>>>>
>>>>> Hi Robert,
>>>>>
>>>>> Dialyzer gets this info from beam_lib:chunks(File, [abstract_code])
>>>>> which corresponds to the AST and is included in beam files if +debug_info
>>>>> is used while compiling.
>>>>>
>>>>> To my knowledge there is no reason to not let sources be combined
>>>>> (except perhaps when building a PLT), but the implementation seems to
>>>>> require uniformity.
>>>>>
>>>>> Relevant functions:
>>>>> dialyzer_utils:get_abstract_code_from_{src,beam}/{1,2}, get_spec_info/3,
>>>>> get_record_and_type_info/1.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Stavros
>>>>>
>>>>> On Mon, Nov 17, 2014 at 4:53 PM, Robert Virding <rvirding@REDACTED>
>>>>> wrote:
>>>>>
>>>>>> From where does dialyzer get the user added type and spec info? From
>>>>>> the AST, or from Core erlang which contains the same type/spec data? And
>>>>>> why? Can I control it?
>>>>>>
>>>>>> An extra question: why doesn't dialyzer allow me to mix input from
>>>>>> both .erl and .beam files? Or does it and I have missed that?
>>>>>>
>>>>>> Robert
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> erlang-questions mailing list
>>>>>> erlang-questions@REDACTED
>>>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
> --
>
>
> *José Valim*
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Lead Developer
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20141117/080af2d4/attachment.htm>