Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

There are instances where not exporting a type is valid, even if it's used in a spec. #308

Open
elbrujohalcon opened this issue Mar 6, 2023 · 0 comments
Labels
Milestone

Comments

@elbrujohalcon
Copy link
Member

Bug Description

In the module I'm showing below, Elvis will ask me to export the state/0 type. That's not a good idea.

To Reproduce

Run Elvis on this module:

-module(x).

-behaviour(gen_server).

-record(state, {a = field}).

-type state() :: #state{}.

-export([init/1, handle_cast/2]).

-spec init(_) -> {ok, state()}.
init(_) -> {ok, #state{}}.

-spec handle_cast(_, state()) -> {noreply, state()}.
handle_cast(_, State) -> {noreply, State}.

You'll get…

# src/x.erl [FAIL]
  - export_used_types (https://github.com/inaka/elvis_core/tree/main/doc_rules/elvis_style/export_used_types.md)
    - Type state/0, defined on line 7, is used by an exported function but not exported itself

Expected Behavior

No warnings.

Proposed Solution

We already faced a similar issue in rebar3_hank. Until erlang/otp#4847 is dealt with and we get the ability to specify dynamic callbacks, Elvis should avoid emitting this type of warning for types used in exported functions of modules implementing a behavior.
It may be slightly smarter and (just like hank) use the fact that some behaviors (like gen_server) are well-known and they don't have dynamic callbacks.

@elbrujohalcon elbrujohalcon added this to the 3.0.1 milestone Mar 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant