Radek Szymczyszyn
Radek Szymczyszyn
As a followup to #429 I've stumbled upon `test/should_fail/covariant_map_keys_fail.erl`. There's no error reported for `kaboom/0` by default (even with the `--infer` flag), but there is if we apply the following...
This is a list of all self-gradualization errors remaining after #427. ``` ebin/gradualizer.beam: The operator '++' on line 154 at column 58 is expected to have type _TyVar-576460752303423291 which is...
The following type cannot be checked for exhaustiveness: ```erlang -type complex_t() :: {string, string()} | {list, list(allergen())} | {atom, atom()} | {binary, binary()} | {record, record()} | {map, #{non_empty :=...
During work on #404 it turned out that checking functions with intersecting spec clauses is not complete: ``` $ cat clauses_intersect.erl -module(clauses_intersect). -export([foo/1]). -spec foo(bar) -> bar; (baz) -> baz....
> Do we really always need to disable exhaustiveness-checking when a pattern is nonexhaustive? For example we could give an error for f below, but for g we can't know....
Another crash from #373: ``` apps/aecore/src/aec_peers.erl escript: exception error: no function clause matching gradualizer_lib:pick_value({type,0,pid,[]}, ... ```
Even with #404 when running `make gradualize` we get this report: ``` ebin/constraints.beam: The clause on line 43 at column 1 cannot be reached ``` The problematic code from `constraints.erl`...
See https://github.com/josefs/Gradualizer/blob/3cda2e5aa1b1313b3e02fce67986fcda3ab9a02c/src/typechecker.erl#L3680-L3682 and https://github.com/josefs/Gradualizer/blob/3cda2e5aa1b1313b3e02fce67986fcda3ab9a02c/src/gradualizer_int.erl#L61-L68 Specs of both these function say the return values are `type()` (aka `gradualizer_type:abstract_type()`), but that's not the case. This leads to issues with self-gradualizing, see #408.
A warning of this kind pops up multiple times in the self gradualization log and seems to be connected to list/non-empty-list exhaustiveness checking. When the order of clauses is changed...
These two seem to be similar, but according to some comments here in issues and in the code they are significantly different. The source code comments say: ``` %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%...