Replace cabal project parsing with Parsec

[typedrat]

I plan on doing this, since as it stands I don't see a way to implement the sort of overriding syntax needed for #5522, and even if it is possible we should eat our veggies.

[phadej]

@typedrat if you can pull it off, it would be super super great!

[Cmdv]

Is the idea here to use the internal Parsec representation /cabal/Cabal-syntax/src/Distribution/Parsec/?
If so where should one start looking for project parsing?

[ulysses4ever]

Is the idea here to use the internal Parsec representation /cabal/Cabal-syntax/src/Distribution/Parsec/?

Yes.

If so where should one start looking for project parsing?

I was wondering this myself, and it was tricky. At this point, rather than waiting for someone knowledgeable to reply, I'd compile it with profiling on, run it with -xc on a buggy project file, see it failing and study the stack trace...

[ulysses4ever]

where should one start looking for project parsing?

Less discouraging answer is: mostly, https://github.com/haskell/cabal/blob/master/cabal-install/src/Distribution/Client/ParseUtils.hs

[Cmdv]

@ulysses4ever thanks I took a look prior to your comment but never came back to ask about what the "buggy project" was, as the linked issue was a little above my head right now 😓

if you have a small example of what I'd need to run to see this error that would be great, in the mean time I'll also look at the linked file you've given 👍

[ulysses4ever]

By buggy I meant a project file with a parse error. This should throw an error from the parser and inspecting the stack trace from the error should bring some insights on where the parser is located and how it's called.

I'll see about an example but don't hold your breath, please.

[Cmdv]

ah ok I'm with you not to worry cheers for the help... I'll report back if I start this and if not then someone else can take a look.

[jgotoh]

@Cmdv as you did not report back I suppose you did not start yet? I would love to tackle this issue.

I investigated the current project parsing as @ulysses4ever suggested:

It leads to a parse error thrown in Distribution.Deprecated.ParseUtils. The legacy parser lives in this module and also in Distribution.Deprecated.ReadP.
Using traceStack got me to Distribution.Client.ProjectConfig.readProjectFileSkeleton.
It initiates parsing of cabal.project by a call to Distribution.Client.ProjectConfig.Legacy.parseProjectSkeleton, returning an IO (ParseResult ProjectConfigSkeleton).

ProjectConfigSkeleton is defined as type ProjectConfigSkeleton = CondTree ConfVar [ProjectConfigImport] ProjectConfig, no deprecated types here so I guess this requires no change.

I searched for an example usage of the new Parsec module and found parseGenericPackageDescription, I plan to implement something similar.
For example parseGenericPackageDescription :: BS.ByteString -> ParseResult GenericPackageDescription will be something like parseProjectConfigSkeleton :: BS.ByteString -> ParseResult ProjectConfigSkeleton.

[ulysses4ever]

@jgotoh I can confirm that all your findings make sense to me. Godspeed with your experiment. Do ask questions when stuck and try to post a draft PR early — even if it doesn't do much yet.

[Cmdv]

@jgotoh you are right I wasn't able to get time to go too far into this!! looks like you've done some very good investigative work 👌 I'll pass the torch over to you (though I only ran a couple a metres 😂)

[jgotoh]

Many thanks to both of you! :) I will keep you updated and will try to create some rough draft soon to gather some feedback. Most updates will happen on weekends though because of work.