This PR hardcodes knowledge about operators, removing the need to initialize a ProcessContext. This helps remove a bunch of code.
For convenience, I've added a Elm.Parser.parseToFile, which is the same as Elm.Parser.parse followed by Processing.process Processing.init, so that you can get a File directly instead of a RawFile.
I've also deprecated Elm.Parser.parse as that one is now unnecessary complex. I plan for the next major version to remove it and to rename Elm.Parser.parseToFile to Elm.Parser.parse. The deprecation is done in such a way that running the NoDeprecatedelm-review rule would report usages.
I recommend to review this PR commit by commit.
(cc people who use elm-syntax @miniBill @mdgriffith @MartinSStewart and more...?)
About #66
In the long run, I think we should get rid of even the internal post-processing (at least as much as possible).
In #66, the decision was to keep the operators in the processing context, which would be useful to compute lookup tables for instance. While that seems useful (and it is, we have it in elm-review), I don't think it's useful to have module name lookup tables if the AST is not able to include the data (currently that would be done by overriding the module name as written literally in the code). I think we could come back to post-processing if we ever decide to include something like this.
Fixes #175 (and in a way supersedes #66)
This PR hardcodes knowledge about operators, removing the need to initialize a
ProcessContext. This helps remove a bunch of code.For convenience, I've added a
Elm.Parser.parseToFile, which is the same asElm.Parser.parsefollowed byProcessing.process Processing.init, so that you can get aFiledirectly instead of aRawFile.I've also deprecated
Elm.Parser.parseas that one is now unnecessary complex. I plan for the next major version to remove it and to renameElm.Parser.parseToFiletoElm.Parser.parse. The deprecation is done in such a way that running theNoDeprecatedelm-reviewrule would report usages.I recommend to review this PR commit by commit.
(cc people who use
elm-syntax@miniBill @mdgriffith @MartinSStewart and more...?)About #66
In the long run, I think we should get rid of even the internal post-processing (at least as much as possible).
In #66, the decision was to keep the operators in the processing context, which would be useful to compute lookup tables for instance. While that seems useful (and it is, we have it in
elm-review), I don't think it's useful to have module name lookup tables if the AST is not able to include the data (currently that would be done by overriding the module name as written literally in the code). I think we could come back to post-processing if we ever decide to include something like this.