Context needed for ParseFailed: >= 1.2.* #989

Closed
malthe opened this Issue Aug 6, 2012 · 8 comments

Comments

malthe commented Aug 6, 2012

I had a build-depends section with a trailing comma, a syntax error which is arguably hard to spot.

Cabal gave me this error:

cabal: <name>.cabal:<lineno>: Parse of field 'build-depends' failed.
  1. The <lineno> was always the first line of the build-depends section, not the last (which had the syntax error).
  2. There is no mention of the character that failed to parse.

Can we improve this? The logic is defined in ParseUtils.hs. I find the code there to be a little dense and wasn't sure how to get started.

letmaik commented May 17, 2013

+1

I just had this problem for base >= 4.* and had no idea what was wrong, until I realized that * and >= might not make too much sense together. It works with > 4 and == 4.*.

@ttuegel ttuegel added this to the Cabal-1.24 milestone Apr 23, 2015

+1

A little thing that might waste people's time. I'll try to look into it later.

Collaborator

phadej commented Oct 22, 2015

After #2879 is merged, there will be more context to get better error.

I am a Haskell newbie and this issue frustrated among many such small things. I did not know what's wrong, it just printed a message saying "NoParse "build-depends" 23". Line 23 did not have any problem. the problem was on a later line. I had to start with a bare minimum build-depends line and incrementally build it until I got to the problem. It was someone else's code so I had no idea where exactly the problem might be in the long list of dependencies.

Until it gets fixed it might frustrate more people like me. Basic tools like cabal working smoothly is important for Haskell adoption. I appreciate the efforts of those working on getting it fixed.

BTW - the issue for me was exactly the same as neothemachine reported above i.e. a "<=" comparison with "x.y.*".

@23Skidoo 23Skidoo modified the milestones: Cabal 1.24, Cabal 1.26 Feb 21, 2016

@ezyang ezyang modified the milestone: Cabal 2.0 Sep 6, 2016

msteffen commented Aug 20, 2017

I encountered this issue as well:

build-depends:
    base >=4.10 && < 4.11,
    vector >= 0.12.*

As a relative Haskell newbie, I think a clearer error message for this type of mistake might have helped me catch it faster

Owner

hvr commented Aug 21, 2017

@msteffen and in fact, the new parsers gives you the following work-in-progress error message:

Warning: z.cabal:8:12:
unexpected '>'
expecting ",", white space or end of input: "base >=4.10 && < 4.11,\nvector >=
0.12.*"
cabal: Failing parsing "z.cabal".

where the *:8:12 points to the position marked with a caret ^ below

build-depends:
    base >=4.10 && < 4.11,
    vector >= 0.12.*
~~~~~~~~~~~^

it's not ideal yet, but it points you already closer to the cause than the old parser error messages did, even though it's still confusing (I would have expected the * character to be highlighted from a UX POV)

Collaborator

phadej commented Aug 21, 2017

I'll investigate how to make this error message. Probably I'll parse 0.12.* "version ranges" even after >=, but then fail with proper explanation.

And the second point: Printing the line and a caret below shouldn't be too hard. I'll do that when I'll verify that errors actually point to the right place. (IIRC if you have an empty line in build-depends, positions might be off).

@phadej phadej self-assigned this Dec 16, 2017

@phadej phadej added this to the 2.2 milestone Dec 16, 2017

@phadej phadej changed the title from Context needed for ParseFailed to Context needed for ParseFailed: >= 1.2.* Dec 25, 2017

phadej added a commit to phadej/cabal that referenced this issue Dec 25, 2017

Rework version range parser
- No more `try`
- It recognises wild-card version after all operators,
  but fails with more descriptive warning after non-==
  Fixes #989

@phadej phadej referenced this issue Dec 25, 2017

Merged

Issue 989 range op wild #4974

4 of 4 tasks complete

phadej added a commit to phadej/cabal that referenced this issue Dec 25, 2017

Rework version range parser
- No more `try`
- It recognises wild-card version after all operators,
  but fails with more descriptive warning after non-==
  Fixes #989

phadej added a commit to phadej/cabal that referenced this issue Dec 25, 2017

Rework version range parser
- No more `try`
- It recognises wild-card version after all operators,
  but fails with more descriptive warning after non-==
  Fixes #989

phadej added a commit to phadej/cabal that referenced this issue Dec 26, 2017

Rework version range parser
- No more `try`
- It recognises wild-card version after all operators,
  but fails with more descriptive warning after non-==
  Fixes #989

@23Skidoo 23Skidoo closed this in #4974 Dec 26, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment