Open gomoripeti opened 2 years ago
Hey, sorry for taking so long to reply on this
I think it would be better to do the reverse - to make sure, if possible, we always return the richer types on errors. If anything the errors are more informative with potential start & end location of the error, and not just start one.
thanks for the feedback
some pros for the simple location
end_location
makes sense at all in case of tokenizing)error_info()
of erlfmt:read_nodes[_string])
Which one would you prefer?
erlfmt:error_info()
(as in #324)?end_location
is a mandatory field of erlfmt_scan:anno
so then end_location = start_location?). also modify the formatting code (which I am absolutely note familiar with)erlfmt
module only to unify the error_infos coming from different components
This way the return type matches
error_info()
This is an alternative fix for https://github.com/WhatsApp/erlfmt/pull/324