Add support for the -fprof-late flag new in 9.4

[AndreasPK]

---

Please include the following checklist in your PR:

• [X] Patches conform to the coding conventions.
• [ ] Any changes that could be relevant to users have been recorded in the changelog.
• [X] The documentation has been updated, if necessary.

Please also shortly describe how you tested your change. Bonus points for added tests!

---

I tested this locally. Still need to add a changelog entry.

[Mikolaj]

Thank you, that's a long awaited feature! Is this a genuine error in CI or does some hash in a test need updating after your change?

[AndreasPK]

Thank you, that's a long awaited feature! Is this a genuine error in CI or does some hash in a test need updating after your change?

Not sure. I don't know which parts of Cabal affect the hash. I did add some constructors and a new field so it seems possible.

[AndreasPK]

Thank you, that's a long awaited feature! Is this a genuine error in CI or does some hash in a test need updating after your change?

Not sure. I don't know which parts of Cabal affect the hash. I did add some constructors and a new field so it seems possible.

The hash also changes locally when running the tests. I will have to look into that as I don't just wanna update the cache without understanding why it changed. But I'm thankful if anyone has hints how that might have happened.

[Mikolaj]

I looked a little bit closer and I think the hash change is to be expected, since you modify the types that likely go into LocalBuildInfo. So I'd just update the hash and be glad it guards against reverting the change.

[AndreasPK]

I looked a little bit closer and I think the hash change is to be expected, since you modify the types that likely go into LocalBuildInfo. So I'd just update the hash and be glad it guards against reverting the change.

Alright thanks will do in the near future.

[AndreasPK]

Turned out to be not so near but I updated the hash and rebased. Let's see what CI says.

[AndreasPK]

This seems like an CI issue but I'm not entirely sure. Not sure if I have rights to restart CI jobs.

Here is the key error:

Project settings changed, reconfiguring...

creating D:\a\cabal\cabal\cabal-testsuite\PackageTests\SDist\T7124\dist-newstyle\cache

creating D:\a\cabal\cabal\cabal-testsuite\PackageTests\SDist\T7124\dist-newstyle

creating D:\a\cabal\cabal\cabal-testsuite\PackageTests\SDist\T7124\dist-newstyle\cache

D:\a\cabal\cabal\cabal-testsuite\PackageTests\SDist\T7124\dist-newstyle\cache\conE6FD.tmp: renameFile:renamePath:MoveFileEx "\\\\?\\D:\\a\\cabal\\cabal\\cabal-testsuite\\PackageTests\\SDist\\T7124\\dist-newstyle\\cache\\conE6FD.tmp" Just "\\\\?\\D:\\a\\cabal\\cabal\\cabal-testsuite\\PackageTests\\SDist\\T7124\\dist-newstyle\\cache\\config": permission denied (Access is denied.) 

[AndreasPK]

@Mikolaj Any insight?

[Mikolaj]

Yes, I think we are getting this random very breakage often on Windows CI. Restarted.

[Mikolaj]

@AndreasPK: what CI issue? ;P

[AndreasPK]

@Mikolaj Seems CI passes now. Let me know if I need to do anything else.

[Mikolaj]

So it's ready for review, I presume? Let me mark it so and let's hope 2 reviewers show up.

[Mikolaj]

@AndreasPK: do you have any idea for a small test to add to our test suite that would guard against somebody reverting your changes?

A tiny changelog file would be very welcome, see https://github.com/haskell/cabal/blob/master/CONTRIBUTING.md#changelog

[Mikolaj]

@AndreasPK: it would be cool to fit this into cabal 3.10. The windows is closing, though...

[AndreasPK]

@AndreasPK: it would be cool to fit this into cabal 3.10. The windows is closing, though...

I will try to take a look tomorrow.

[AndreasPK]

Please take another look.

[Mikolaj]

Does the test protect from somebody making a change that either completely ignores the new option (compiles without profiling) or makes it work as the normal profiling option?

[AndreasPK]

The test currently only checks if the profiling detail setting is accepted. Not which effect it has.

Ideally we would check for the annotation mode by grepping for the corresponding -fprof-* flag in the ghc invocation. I did spend some time looking into that but couldn't figure out a good way to check for that. Given that I couldn't find any tests for any of the other profiling-detail settings either I settled for the tests as they are.

If you think it's insufficient I would appreciate pointers to any test that does this sort of thing. I found some that look at the runtime output of the built executable but that's not really helpful here.

[Mikolaj]

You are right profiling is woefully undertested. All the more reason to add a bit more fleshed out test. How about something like

https://github.com/haskell/cabal/blob/master/cabal-testsuite/PackageTests/ReplCSources/cabal.test.hs

Would any late show up in -v2 output of a cabal job?

[Mikolaj]

BTW, when you are ready to merge, please set a label (squash+merge_me, I guess?) to let mergify do this, as per our process.

[AndreasPK]

You are right profiling is woefully undertested. All the more reason to add a bit more fleshed out test. How about something like

https://github.com/haskell/cabal/blob/master/cabal-testsuite/PackageTests/ReplCSources/cabal.test.hs

Would any late show up in -v2 output of a cabal job?

That was helpful I've added a test checking for the presence of the flag for ghc-9.4

I briefly tried adding a test for pre-9.4 that get's skipped when ghc is too old but run into some odd errors and I think I exhausted my motivation to work on the tests for this now.

[Mikolaj]

I briefly tried adding a test for pre-9.4 that get's skipped when ghc is too old but run into some odd errors and I think I exhausted my motivation to work on the tests for this now.

Thank you. Let's hope it doesn't format C: with older GHCs. Please feel free to set merge_me or squash+merge_me label and in 2 days this should get auto-merged.

[mergify[bot]]

⚠️ This pull request got rebased on behalf of a random user of the organization. This behavior will change on the 1st February 2023, Mergify will pick the author of the pull request instead.

To get the future behavior now, you can configure bot_account options (e.g.: bot_account: { author } or update_bot_account: { author }.

Or you can create a dedicated github account for squash and rebase operations, and use it in different bot_account options.