Adapt to R devel parser

[lorenzwalthert]

Closes #419. We need to distinguish two cases: Before the parser fix outlined in #419 was committed into R devel and afterwards. The parser version is identified from the parse data. If the parse data contains an equal_assign token, we know it's the second case and say the parser version is 2. If not, we don't know, because parse data for all expressions not involving EQ_ASSIGN can't be distinguished, so we just assume it is version 1.
I propose to use an environment to store specifications about the current run, i.e. to store the parser version. I am not sure if that's a good idea. But since we need to have the parser version available in different places, I can't think of a better way. Also, I am not sure about using version numbers for the parser and if it is a good idea to derive the parser version from the result of parsing. An alternative approach is to base it on the Rversion number, but that's a bit brittle I think. Any comments on that @krlmlr?

[codecov-io]

Codecov Report

❗ No coverage uploaded for pull request base (master@0154a18). Click here to learn what that means.
The diff coverage is 95.23%.

@@            Coverage Diff            @@
##             master     #441   +/-   ##
=========================================
  Coverage          ?   90.51%           
=========================================
  Files             ?       35           
  Lines             ?     1613           
  Branches          ?        0           
=========================================
  Hits              ?     1460           
  Misses            ?      153           
  Partials          ?        0

Impacted Files	Coverage Δ
R/environments.R	100% <100%> (ø)
R/roxygen-examples-parse.R	100% <100%> (ø)
R/nested-to-tree.R	96.42% <100%> (ø)
R/parse.R	83.67% <100%> (ø)
R/relevel.R	95.31% <87.5%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0154a18...25b0e28. Read the comment docs.

[lorenzwalthert]

I guess we best merge this now for the release. As this is internals only, we can change it later if necessary.

[krlmlr]

Thanks. I think we can rely on the R version here, because the fix is unlikely to be back-ported to R 3.5 (and even if, we still can do that).

I like the way relocate_eq_assign() works. Is it early enough that we can assume that for all R versions (3.6 and < 3.6) the data format is essentially the same? Maybe we don't need to distinguish anything for the nested parse data?

[krlmlr]

What happens if we leave "EQ_ASSIGN" here unconditionally?

[lorenzwalthert]

Not sure. A few changes in #441 did not have any known effects on the styling, it's just about making the AST look the same. But probably it would break something because there was some reason why it was not included in the list I guess.

[lorenzwalthert]

The thing is that styler needs to pass R CMD CHECK on R devel and the patch mentioned in #49 is not going to be in R before 3.6. So I am not sure how I should use the R version for distinction in this case.

Is it early enough that we can assume that for all R versions (3.6 and < 3.6) the data format is essentially the same?

I am not sure if I understand this. The reason we have #419 is that it is (as of today) not the same.