more liberal white space parsing in the the mixin field #5293
Conversation
|
The travis builds are failing left right and center. However, I do not think it is this commit that is responsible for it. Noticed that there are some further commits on the master branch which is supposed to fix some of the travis builds. Please feel free to give feedback on what is the best course of action. |
|
The missing piece is to make cabal-install executable realise that it can now handle CabalSpec = 3.0. After chat with @phadej on IRC, I came to understand that this version is taken from the version of Cabal package. However, a mere bumping up of Cabal version and cabal-install versions would not work as there is the package hackage-security which I guess has an upperbound on Cabal version. That too is needed to be updated. |
|
Hmm, |
|
@piyush-kurur, thanks a lot for taking this on. I also had the "easy" version of this patch languishing on my local copy, but it's a bit more work getting all of the CabalSpec in order. Very happy to see it being done. |
| @@ -115,18 +135,21 @@ instance Text ModuleRenaming where | |||
| parse = do fmap ModuleRenaming parseRns | |||
| <++ parseHidingRenaming | |||
| <++ return DefaultRenaming | |||
| where parseRns = do | |||
| rns <- Parse.between (Parse.char '(') (Parse.char ')') parseList | |||
| where lparen = Parse.char '(' >> Parse.skipSpaces | |||
There was a problem hiding this comment.
quick comment: don't touch parse = at all. It's hopefully not used anywhere, and better to keep it as 2.0 version. (The more incentives to upgrade to parsec variant there are, the better)
There was a problem hiding this comment.
Okey. I will remove it in further commits.
|
@23Skidoo Do you recommend rebasing? I have found github pull requests that are rebased to be quite confusing. |
| @@ -87,18 +104,21 @@ instance Parsec ModuleRenaming where | |||
| -- NB: try not necessary as the first token is obvious | |||
| parsec = P.choice [ parseRename, parseHiding, return DefaultRenaming ] | |||
| where | |||
| lparen = P.char '(' >> liberalSpaces | |||
| rparen = P.char ')' >> liberalSpaces | |||
There was a problem hiding this comment.
@phadej The liberalSpaces parser just checks for appropriate cabal version and then skips spaces. For lower versions of the cabal spec it says gives an error if there is space. So far so good but I noticed that the spaces stuff was not needed in the version 2.2 case for rparen as there is a P.spaces after its call. Further down the code in the hiding clause there is no P.spaces used which means that the rparen there does not skip spaces (in the version 2.2 behaviour)
If we want to maintain complete bug compatibility, then this will lead to a rather convoluted rparen behaviour. I feel this will eventually lead to more confusing whitespace behaviour in the end and the code will be pepperd with
various flavors of paren-parsers (some that skips spaces and some that do not).
There was a problem hiding this comment.
The question therefore is shall I replace the rparen definition with
rparen = P.char ')' >> P.spaces
This is not really compatible with V2.2 I think due to the use of rparen in the hiding clause.
There was a problem hiding this comment.
I just realised that this has implication to some of the tests that failed. So let me send a commit with the above version of rparen. If you find it not okey I will revert it again.
|
@piyush-kurur If you haven't yet decided on a way to structure the old and new parsers, I'd recommend just doing a straight up copy paste of the entire grammar and having two copies. |
|
@ezyang What you say makes sense. I will make the necessary changes and get back. |
|
@ezyang I have kind of done what you have asked me. There are two questions that I want to make
|
|
LGTM, though @phadej should probably sign off on the BC bits (I don't quite understand the correctness criterion here.) Happy to merge it in a few days if radio silence. |
|
(and yes, I would squash) |
|
@ezyang Okey I will do the squash. Also @phadej please hold on merging this change as there is one piece still missing. The cabal-install executable should be made to realise that it can now handle V3 specs. As I remarked in the previous comment, this requires changing the version in the .cabal files of Cabal, cabal-install and I think also hackage-security. Is that all that is required ? |
piyush-kurur
force-pushed
the
whitespace-issue
branch
from
ebb6a67
to
05105c2
Compare
|
@ezyang done the squash |
not necessarily; we just need to infer (or hard-code) a "rounded up" value as the current spec version; something we should do anyway as it would simplify our workflow. |
|
@hvr. Do let me know then how to proceed from here. Is there any plans to sync Cabal (the file format) specs with Cabal (the library version) ? |
|
Also test case. I have a failing case that I have mentioned in #5292. Let me know how this can be added to the testsuite. |
|
@phadej, can you please take a look at this? |
|
any updates on this? |
It mentions the issue of parsing failures caused by the presence of blank spaces after opening parentheses. See haskell#5150, haskell#5292, haskell#5293.
|
@phadej, can you please take a look? |
|
There's a specific mention of this in the docs that will need to be removed once this is merged. |
|
merged as #5514 |
The documentation for the "mixins:" field still featured an obsolete warning about a parsing bug which was solved in haskell#5293 and haskell#5292.
The documentation for the "mixins:" field still featured an obsolete warning about a parsing bug which was solved in haskell#5293 and haskell#5292.
This is not yet complete. It is sent for review.
[ci skip]is used to avoid triggering the build bots.I will add the test cases when I get a go ahead on the commits so far.