cabal-install: dynExe+profExe requires prof+dyn

[sheaf]

This commit updates the logic in cabal-install's elaborateInstallPlan function to ensure that we don't try to build a profiled dynamic executable if the compiler doesn't support the profiling dynamic way.

This brings the logic in cabal-install in sync with the Cabal configureProfiling function, which sets withDynExe to false if the user wants a profiled executable but prof+dyn is not supported by the compiler.

---

Template B: This PR does not modify behaviour or interface

E.g. the PR only touches documentation or tests, does refactorings, etc.

Include the following checklist in your PR:

• Patches conform to the coding conventions.

[sheaf]

I haven't managed to write a test for this, because the way things currently work, we compute e.g. whether to build a prof+dyn executable in cabal-install, but then when we invoke ./Setup configure we re-compute this information. I tried writing a test that was based off printPlan but that has the same problem, as that calls the computeEffectiveProfiling function from the Cabal library, thus re-computing that field as well.

Thus, the underlying issue only manifests if you directly call the configure function in Cabal from within cabal-install, like I'm doing in #9871. In that case, the problem is detected by the existing ProfShared test (which fails without this change).

I'm not including a changelog entry either as this should be invisible to users.

[mergify]

This pull request has been removed from the queue for the following reason: pull request branch update failed.

The pull request can't be updated.

You should update or rebase your pull request manually. If you do, this pull request will automatically be requeued once the queue conditions match again.
If you think this was a flaky issue, you can requeue the pull request, without updating it, by posting a @mergifyio requeue comment.

[mergify]

This pull request has been removed from the queue for the following reason: pull request branch update failed.

The pull request can't be updated.

You should update or rebase your pull request manually. If you do, this pull request will automatically be requeued once the queue conditions match again.
If you think this was a flaky issue, you can requeue the pull request, without updating it, by posting a @mergifyio requeue comment.

[Mikolaj]

Let me try first to rebase with mergify rebase.

[Mikolaj]

@mergify rebase

[mergify]

rebase

✅ Branch has been successfully rebased

[mergify]

This pull request has been removed from the queue for the following reason: pull request branch update failed.

The pull request can't be updated.

You should update or rebase your pull request manually. If you do, this pull request will automatically be requeued once the queue conditions match again.
If you think this was a flaky issue, you can requeue the pull request, without updating it, by posting a @mergifyio requeue comment.

[ulysses4ever]

same result as I had

[Mikolaj]

I think we have no choice but to change the merge label to merge_no_rebase.

[Mikolaj]

And while we ponder that, let me rebase with github, for science.

[Mikolaj]

Oh dear, I merged instead of rebasing. My bad.

[Mikolaj]

@mergify rebase

[mergify]

rebase

✅ Branch has been successfully rebased

[Mikolaj]

Phew, mergify rebase killed the merge commit.

[ulysses4ever]

In my experience, no matter how you rebase (with the mergify command, with GitHub UI, or locally), the catch is to have the master branch untouched by the time CI finishes after rebasing. If this is the case, the bot will auto-merge. If the master branch has advanced, you're back exactly to the same point where you were before rebasing.