This repository has been archived by the owner on Jun 11, 2023. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
So, Elixir 1.6 is out and has some interesting new features (though none I plan to adopt in the near future, hence the low priority).
The main change for us was the deprecation of
Map.replace/3
, which I've migrated to usingMap.replace!/3
instead (which is, indeed, the desired behaviour).But some low level compiler change (I'm assuming) happened that modified the final binary output, resulting in some compilation warnings and dialyzer errors[1].
The main low level change that affected us is that the code snippet below, that automatically handles the fallback, yields a "the above clause will always match" warning.
Mind you, the warning is absolutely correct! But remember that the snippet above is inside a macro, and as such is a generated code. If the
event
variable is a pattern match like%{foo: :bar}
, the fallback clause will be valid and no warning is generated. But ifevent
is a catch-all variable, then the fallback is useless and a warning will be emitted (though that did not happen on 1.5.x or before).There's a simple fix for this: put
generated: true
on thequote/2
macro. But that comes with a caveat: since we are telling Elixir that code is generated, typespec verifications from dialyzer will be ignored.It is possible to conditionally generate the fallbacks (based on the input of
event
or whatever variable the macro receives) without usinggenerated: true
. Something like this:The problem with this approach is that the code will be significantly more complex and harder to read.
Not to mention the several fallback cases we have on e.g.
Process.Executable
, which are generated at__before_compile__
level (and thus we'd need to track the input variables with module attributes).So, while deprecation warnings were fixed, I'm still delaying the Fallback/Dialyzer fix because I don't like neither option. Maybe I'll have some insight that enables a simple fix without
generated: true
, but so far that seems unlikely.Progress
Incidental
Notes
[1] - It may be related to elixir-lang/elixir#7224, since Phoenix relies heavily on macros / generated code, but I did not look further.
This change is![Reviewable](https://camo.githubusercontent.com/23b05f5fb48215c989e92cc44cf6512512d083132bd3daf689867c8d9d386888/68747470733a2f2f72657669657761626c652e696f2f7265766965775f627574746f6e2e737667)