-
Notifications
You must be signed in to change notification settings - Fork 724
Add new-haddock support for --haddock-for-hackage
#4490
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
There are still two Orphan instances for Currently trying to fix those. |
|
Re the test suite failures, look at Unfortunately the need to make the change here is irritatingly non-discoverable. |
|
Thanks! That one is hard to find indeed. I added it and updated my PR, however the unit-tests still fail at |
|
I don't see any obvious problems, so it's time to put on the debugging gloves.
Bonus points if you fix the test to print this for you. |
|
Ok so apparently the problem is that the printparse roundtrip test fails. It checks whether the ProjectConfig stays unaltered after parsing it, by printing it out again and comparing. The check fails then because Working on it. |
|
The bug is probably in This may also explain why this flag was not supported in the first place :) |
|
Ok so I updated this as well, changed the
This did also not fix the error. However what did fix the error was changing the arbitrary instance of Regardless of how |
This commit fixes one instances of a general bug where noFlag command line flags do not translate correctly when converted into the field description format (and in fact, cannot be converted correctly.) The bug goes something like this: 1. A noArg command line parser translates into a "choice" command line parser, for which there is only one choice (the flag that would be set when you toggle it on.) 2. Choice command line parsers get translated into the field format by having a rendering for each defined choice, and then default to empty (omit the field entirely) if no choices apply. 3. This means that NoFlag and the "default choice" (if you hadn't specified the flag at all) render identically, because there is never a choice for the default choice in the no arg field. In the interest of getting this to work, I manually made for-hackage work correctly, but there is probably a way to refactor this into a more universal fix. CC @dcoutts Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
Yes, it looks like I was wrong about what the problem was. More below.
Yes, but if you do that, then we won't be testing that I built your branch and ran the REPL command on the three different variants of In fact, this is enough to determine what this bug is. Recall that this is a round-trip test: we're seeing if we can get exactly the same structure back after serializing it. When we see that So, the correct fix is to make it so Unfortunately, the way this jiggery-pokery works is completely undocumented, so after having done this investigation I went ahead and wrote the fix. I'll push it onto your branch shortly. |
|
I pushed a387779 to your branch. Take a look at it and see if you agree with the reasoning in the commit message. |
|
Ah I see now! That part confused me as the defaultFlags were the first thing I looked at after following the way the printparse check works, and I got stuck there and fixated on it. a387779 makes sense in that regard, I agree :)
Yeah that I was aware of, I mostly did it to get closer to the actual problem, not a very elegant approach by me though. |
|
@ezyang @bitrauser what's the status here? what's the next steps? who needs to do something? |
|
@hvr With the latest update on this PR, the So I was waiting for this to be approved :) |
|
@bitrauser Well, the TEST_OTHER_VERSIONS=YES build-config is broken; IOW, if all works except that single build-config, then I'd consider CI passed as far as this PR is concerned. |
| packageConfigHaddockHscolourCss :: Flag FilePath, --TODO: [required eventually] use this | ||
| packageConfigHaddockContents :: Flag PathTemplate --TODO: [required eventually] use this | ||
| packageConfigHaddockContents :: Flag PathTemplate, --TODO: [required eventually] use this | ||
| packageConfigHaddockForHackage :: Flag HaddockTarget |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fwiw, this looks somewhat inconsistent; we got a field named ForHackage which would imply a Bool, but then this holds an enum which redundantly says ForHackage (or ForDevelopment).
Why isn't this simply a Flag Bool?
PS: To answer my own question, now I see that this has been inherited from Distribution.Simple.Setup (haddockForHackage :: Flag HaddockTarget); so this PR just went along with the pre-existing design decision...
...and actually in #2852 this was still a Flag Bool... it was 0975372 which lateron introduced the HaddockTarget data type w/o addressing the introduced naming inconsistency...
|
Yes, CI is independently broken, see #4516 @bitrauser feel free to merge, I'll try to debug and fix the CI failure soon. |
Greetings everyone, this is my first pull request here.
I added support for the
--haddock-for-hackageflag, the associated issue is #4412 .I'm happy for any kind of feedback.