Until now, "%x{__struct__: y}" would ignore the ":__struct__" part and only
use/match on "x", without warnings. With this commit, a warning is emitted in
this case and in the respective case when updating ("%SomeStruct{x | __struct__:
y}").
Fixes [issue 5602](https://github.com/elixir-lang/elixir/issues/5602)
Erlang does not accept map_field_exact tag for map used as map keys
since it does not perform any matching on map keys.
For example this fails:
$ erl
Erlang/OTP 19 [erts-8.2] [source-a2c5a92] [64-bit] [smp:8:8]
[async-threads:10] [hipe] [kernel-poll:false]
Eshell V8.2 (abort with ^G)
1> #{ #{1 => X} := 3 } = #{ #{1 => 2} => 3 }.
* 1: illegal map key in pattern
Change how we mark the generated AST for suppressing dialyzer errors -
instead of [generated: true, location: 0], we provide proper line number.
This means, however, that on OTP 18, those nodes won't be recognized
as generated and warnings will be issued.
It was decided that proper error messages are more important than
avoiding bogus dialyzer warnings.
The old mark for generated code is left in places that made compiler
issue warnings on 18.
The bad remote call dialyzer warnings can be suppressed with the
@dialyzer :no_fail_call
module attribute.
With changes to OTP 19, dialyzer started emitting warnings for
the struct update syntax where variable could only be that struct.
For example:
def foo(%Foo{} = struct), do: %Foo{struct | bar: :baz}
In previous versions, when trying to compile a file and the file
depended on a module that was not yet compiled or was unavailable,
the parallel compiler would wait until the missing dependency shows
up. In case it did not, the compiler would "release" the file being
compiled, disabling any further missing dependency resolution.
This lead to issues in code like the following:
Code.ensure_compiled(SomeModuleThatWontBeAvailable)
%SomeStructFromMyProject{}
Because `SomeModuleThatWontBeAvailable` would never be available,
the file above would block until released. When released, the
parallel compiler would disable further lookups for that file,
meaning we would no longer wait for missing dependencies when we
attempt to load the struct.
In the majorify of cases, the struct would already be available,
which meant compilation would work. But if the file that defined
the struct was also blocked by the compiler (and consequently
released), compilation would be non-deterministic.
This patch solves the issue by removing the "release" behaviour
from the compiler. If a dependency is not available, we will
notify the file of such and move on, with the parallel compiler
still enabled. In order to guarantee this works without
introducing deadlocks, the parallel compiler now also knows which
module is being defined by a given file, building a graph and
solving dependencies from the leaves. In case it is a cyclic
graph, we will raise that a deadlock was found.
Closes#4294Closes#4055
This allows modules that have recursive dependencies on structs
to be defined by having a fine grained control on the struct
definition besides the module one.
Ivan Kozik
José Valim
Michał Muskała
Andrea Leopardi
Aleksei Magusev
Gal Tsubery
Eric Entin
eksperimental
Eric Meadows-Jönsson