Support location specifying in pipe op #69
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Premwoik
force-pushed
the
support-loc-specifying-in-pipe-op
branch
2 times, most recently
from
3a913c3 to
90d26e6
Compare
Contributor
|
@Premwoik This one is still marked as a draft. Is it ready to review/merge? |
Collaborator
Author
You can take a look if you have time :) I kept this one as a draft because I was not sure if it won't break something. |
joaothallis
reviewed
May 25, 2022
Provide small improvements to make the new tests passed on each Elixir version.
Premwoik
force-pushed
the
support-loc-specifying-in-pipe-op
branch
from
a96c553 to
b2b3a00
Compare
Co-authored-by: João Thallis <joaothallis@icloud.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This resolves #9 and finally handles specifying location with the tokens in the pipe operator.
Before
Now
Solution
Added a check to the
callmapper if the first token is a|>. If true and if the firstcallarg is a lineless expression (an expression that could be without location) then the line inoptsis set to 0. Thus the tokens before thiscallline are not dropped and the lineless expression can find the correct line in tokens.Problem
Conversion of some Elixir functions to the Erlang functions that take the result as second arg instead of the first one.
For example, the
elem(result, pos)function is converted to the Erlangelement(pos, result).It is solved by detecting when the call is to function from the
:erlangmodule and if it is, the first and second args are swapped. After specifying lines the correct args order is restored.New testing format for specifying expressions
This PR proposed a new testing format for specifying expressions similar to the one for the type pretty-printer. Test cases can be defined in the
Gradient.AstDatamodule. Each case contains the input values and the expected result. Thanks to this the expression specification can be tested without adding a new.exfile and compiling it.I am still thinking about how to make it more pretty and flexible.