• Correctly handle WayDyn in mkPluginUsage

• Correctly handle WayDyn in mkPluginUsage

• Correctly handle WayDyn in mkPluginUsage

Seems there’s another bug: https://ghc.haskell.org/trac/ghc/ticket/15492

Use filterM and add tests

@monoidal I'll switch to just using filterM. w.r.t a test I'll see what I can do: I'd need to figure out how to either get A: two library search paths for a package, or B: get two libraries for one package.

• Track object files of plugin in usages

• Plugin dependency information is stored separately
• Track object files of plugin in usages

• Plugin dependency information is stored separately
• Track object files of plugin in usages

@mpickering @bgamari This patch is ready for review now

• Track object files of plugin in usages

• Track object files of plugin in usages

• Plugin dependency information is stored separately
• Track object files of plugin in usages

Alright... I now understand how actually work checkDependencies: It checks whether all the current imported modules are equal to the imported modules from the last compilation run. If there's any difference, a recompile is triggered.
So what used to happen, before @mpickering's patch, is that plugin modules were never added to the field that stores the previously imported modules, and so plugins always triggered recompilation.
So after @mpickering patch, the plugins got added to the field that stores the previously imported modules, and so recompilation is no longer triggered automatically.
All my patch is currently doing is storing those plugins in a different field, which is only used by checkDependencies, and doesn't mess up the rest of GHC.

@mpickering No I didn't test it. But now on the offical ghc8.6rc1-alpha I'm having great difficulties triggering a recompilation of A.hs that uses the B.hs plugin by changing the source of B.hs when B is declared a pure plugin.

This change removes the Eq instance for UniqSet: was this intentional? If so, why? If not, could this be added?

• zonkCt tries to maintain the canonical form of a Ct.

• zonkCt tries to maintain the canonical form of a Ct.

• Add a test for Trac #11525
• zonkCt tries to maintain the canonical form of a Ct.

Sound OK?

It seems that

In D3105#90929, @simonpj wrote:

I'd much prefer to follow comment:7 on Trac Trac #11525. Was there some reason you chose not to do that?

• Fix T11525 test case

In D3024#90078, @bgamari wrote:

In D3024#90069, @mpickering wrote:

I think I agree with @christiaanb about this. What is the benefit of adding natural literals to core? Trac #13186 provides no motivation and this patch provides no motivation for changing the non-core representation to be Natural. It seems much easier to keep the internal representation as Integer and convert it once to a natural in a library somewhere if that is the evidence you want to provide.

I think there is an argument that can be made either way here. I'm personally rather agnostic on the question and would have been happy to continue using an Integer representation but I can see why @dfeuer would object that we should be more precise in our types. I think David would say that the fact that Nat was backed by an Integer should be viewed as a historical mistake and we should be writing the code that we want, not the code that we happened to stumble our way into.

Seeing this is already merged, I guess I'm too late to object to the current implementation. Anyhow, my question is, why is this implementation chosen instead of either:

I (sadly) don't see myself working on reinstating -fmax-worker-args. However, given that it was unintentionally rendered a no-op during improvement of the demand analysis phase, I would think removing it entirely is a mistake. Instead, I think it would be better if GHC issued a warning that -fmax-worker-args is currently a no-op.

• -fno-strictness implies -fno-worker-wrapper

• -fstrictness implies -fworker-wrapper

I'm OK with -fstrictness implying -fworker-wrapper. However, it would be an exception to the (currently implemented) rule, when -O -fno-strictness would then also imply -fno-worker-wrapper. See also: http://git.haskell.org/ghc.git/blob/HEAD:/compiler/main/DynFlags.hs#l3601

• Remove copy-paste error

In D1115#30562, @bgamari wrote:

@christiaanb, might it also make sense to handle Cabal issue 2689 (ensuring framework headers are in the include path) here as well? Or will this be taken care of for us by -framework?

• Refactor get(Pkg)FrameworkOpts

• Replace negative -fcpr-off by positive -fcpr-anal

In D1110#30555, @simonpj wrote:

That's good, thanks. But let's make it a positive flag, like -fstrictness (on by default in -O, -O2). Maybe -fcpr-anal?

Rebase against latest master so that harbormaster will hopefully build

• Revert "Make -fcpr-off a dynamic flag"
• Second try: Make -fcpr-off a dynamic flag

In D1110#30368, @simonpj wrote:

Not much thought was given to how -fcpr-off works.

Currently its works by not *generating* CPR info.

But an alternative would be not to *exploit* CPR info, specifically during worker/wrapper generation. The advantage is that this is done in ONE place, namely mkWWcpr, in WwLib. That in turn is called only from mkWwBodies which already gets DynFlags. Easy!

So that would mean that CPR analysis still happens, but GHC generates no w/w split.

I think this would be a better plan. OK?

Yes, I'm happy that there a both the simple wrappers to create constraints, and a way to manipulate the EvBindsVar directly.

This makes ./configure go through on my machine now, where it didn't before this patch.