[erlang-questions] Tricking dialyzer with an opaque type

[Paul Guyot]

Dániel,

Thank you for your reply. Indeed, the drawback of my approach is that the internals of f() are not checked, although this could be done by keeping (and exporting) the function under another name.
dialyzer is ran as part of the integration process and the code is only meant to be executed at compile time.

Paul

> On 28 Jun 2017, at 14:54, Dániel Szoboszlay <dszoboszlay@REDACTED> wrote:
> 
> Why don't you simply run Dialyzer on a build made without your parse transform? It could even verify the internals of f().
> 
> Daniel
> 
> 
> On Sun, 25 Jun 2017, 18:56 Paul Guyot, <pguyot@REDACTED <mailto:pguyot@REDACTED>> wrote:
> Hello,
> 
> I do have a parse transform that replaces the body of a 0-arity function with its result, as evaluated at compile time.
> I am looking for a way to avoid an opaque violation warning from dialyzer when this function returns, say, a gb_sets:set(). The spec is properly copied into the parsed tree, but dialyzer just ignores it.
> 
> Typically, such a function would load data from a file and create a gb_sets:set() from this data.
> 
> -spec f() -> gb_sets:set(unicode:unicode_binary()).
> f() ->
>         {ok, Content} = file:read_file(?FILENAME),
>         List0 = binary:split(Content, <<"\n">>, [global]),
>         List1 = lists:filter(fun(W) -> W =/= <<>> end, List0),
>         gb_sets:from_list(List1).
> 
> With the parse_transform, dialyzer complains on usage, e.g. :
> 
> [warning] some_module.erl:123 the call gb_sets:add(<VALUE>,Var::{1..1114111,{_,_,_}}) does not have an opaque term of type gb_sets:set(_) as 2nd argument
> 
> Yet, of course, some_module.erl does not violate the opacity of gb_sets:set() itself.
> I can trick dialyzer with an expensive identity function:
> 
>         gb_sets:add(Value, binary_to_term(term_to_binary(Var)))
> 
> Any better idea?
> 
> Paul
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
> http://erlang.org/mailman/listinfo/erlang-questions <http://erlang.org/mailman/listinfo/erlang-questions>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170630/d0c4c575/attachment.htm>