lib/pleroma/web/activity_pub/builder.ex:115:pattern_match
The pattern can never match the type.
Pattern:
_emojo = %{:file => _path}
Type:
nil | binary()
lib/pleroma/reverse_proxy.ex:225:pattern_match
The pattern can never match the type.
Pattern:
:done
Type:
{:ok, :no_duration_limit, :no_duration_limit}
lib/pleroma/reverse_proxy.ex:226:pattern_match
The pattern can never match the type.
Pattern:
{:error, _error}
Type:
{:ok, :no_duration_limit, :no_duration_limit}
lib/pleroma/reverse_proxy.ex:391:pattern_match
The pattern can never match the type.
Pattern:
__duration = nil, _max
Type:
integer(), _
lib/pleroma/helpers/qt_fast_start.ex:129:improper_list_constr
List construction (cons) will produce an improper list, because its second argument is <<_::32>>.
lib/pleroma/helpers/qt_fast_start.ex:129:improper_list_constr
List construction (cons) will produce an improper list, because its second argument is <<_::64>>.
Incorrect spec. Both search backends return :ok so that is what should be the spec.
lib/pleroma/search/database_search.ex:56:callback_type_mismatch
Type mismatch for @callback remove_from_index/1 in Pleroma.Search.SearchBackend behaviour.
Expected type:
{:error, _} | {:ok, _}
Actual type:
:ok
lib/pleroma/signature.ex:30:pattern_match
The pattern can never match the type.
Pattern:
%{<<97, 112, 95, 105, 100>> => _ap_id}
Type:
{:error, _} | {:ok, map()}
I have opted to set this to :upper as this retains the same behavior but clears up the error.
lib/pleroma/upload.ex:178:call
The function call will not succeed.
Base.encode16(binary(), [{:lower, true}])
breaks the contract
(binary(), [{:case, encode_case()}]) :: binary()
lib/pleroma/web/twitter_api/controllers/util_controller.ex:300:pattern_match
The pattern can never match the type.
Pattern:
{:error, :no_such_alias}
Type:
{:not_found, nil}
lib/pleroma/web/twitter_api/controllers/util_controller.ex:304:pattern_match
The pattern can never match the type.
Pattern:
{:error, _error}
Type:
{:not_found, nil}
This check was recently improved in Credo and it does make sense for readability.
The offending functions in Pleroma have been renamed and a couple missing the ? suffix have been fixed as well.
lib/pleroma/web/mastodon_api/controllers/status_controller.ex:333:pattern_match
The pattern can never match the type.
Pattern:
{:ok, _activity}
Type:
{:error, _}
lib/pleroma/migrators/context_objects_deletion_migrator.ex:13:exact_eq
The test :error | float() == 0 can never evaluate to 'true'.
lib/pleroma/migrators/hashtags_table_migrator.ex:13:exact_eq
The test :error | float() == 0 can never evaluate to 'true'.
This is for streaming media to ffmpeg thumbnailer. The existing implementation relies on undocumented behavior.
Erlang open_port/2 does not officially support passing a string of a file path for opening. The specs clearly state you are to provide one of the following for open_port/2:
{spawn, Command :: string() | binary()} |
{spawn_driver, Command :: string() | binary()} |
{spawn_executable, FileName :: file:name_all()} |
{fd, In :: integer() >= 0, Out :: integer() >= 0}
Our method technically works but is strongly discouraged as it can block the scheduler and dialyzer throws errors as it recognizes we're breaking the contract and some of the functions we wrote may never return.
This is indirectly covered by the Erlang FAQ section "9.12 Why can't I open devices (e.g. a serial port) like normal files?"
https://www.erlang.org/faq/problems#idm1127
Mark Felder