No, but the code is here for anyone to use if they wish.

Merged now. https://gitlab.haskell.org/ghc/ghc/commit/c2455e647501c5a382861196b64df3dd05b620a2

Responded to new comments now.

https://gitlab.haskell.org/ghc/ghc/merge_requests/106

I applied Simon's suggestions apart from the one about TcGblEnv which I don't think made the code much clearer as it then wasn't obvious which bits to extract from the TcGblEnv to combine together with the other TcGblEnv in order to get the correct result.

I put the patch on gitlab: https://gitlab.haskell.org/ghc/ghc/merge_requests/49

This patch is now at https://gitlab.haskell.org/ghc/ghc/merge_requests/16

CI passes: https://gitlab.haskell.org/mpickering/ghc/pipelines/460

• remove merge artifacts

I rebased. Last night I tested that the default build works correctly, I fixed the binary-dist target so that it doesn't build haddock with Stage2 libraries and also verified that test works correctly.

• Define and use stageLibaries
• Resolve some more stage confusion
• fix build
• Make things even more consistent
• docs
• Cleanup
• Remove tabs
• Andrey's suggestions
• Implement the finalStage build option
• Note about libffiContext
• Fix lint
• Alp comments
• Use stage1 haddock

• Alp comments

@snowleopard I implement the finalStage solution that @alpmestan suggested. It turned out quite nicely and meant we could remove the stage1Only option.

• Implement the finalStage build option
• Note about libffiContext
• Fix lint

In D5458#150798, @alpmestan wrote:

So I think that is all the packages?

There's a trivial way to find out, ls _build/stage2/lib/package.conf.d/.

In D5458#150792, @alpmestan wrote:

This is looking pretty good. Besides Andrey's outstanding question, I made a suggestion and have one request to add a TODO.

Can you clarify how far this gets you? I don't think the flavour matters much, so I won't ask whether you've built with different flavours. You said you get as far as building a working stage 3 compiler, right? And if you make stagePackages return the whole series of packages that a bindist would ship with, does that work too? Maybe you can just borrow that list from stage2Packages (or alternatively stagePackages Stage2)?

• Andrey's suggestions

I completed a stage3 build from a clean tree successfully with this patch and a modified UserSettings.hs. Another review @snowleopard would be good seeing as it also involved some more radical changes now.

• Remove tabs

• Make things even more consistent
• docs
• cleanup

Still broken in fact, see Trac #16069 for where the problem lies.

I think I fixed things up now. @alpmestan can you review?

• fix build

@DavidEichmann I think it will be much easier if you rebase the patch? This review cycle has been going on for a very long time now.

In D5458#150586, @harpocrates wrote:

I think that stageLibraries also needs to be used in configurePackage to make sure you end up needing packages from the right stage. That occurs here: https://github.com/ghc/ghc/blob/ed69f8bd1fd4b84b62bb4f10eef7f76e537be07b/hadrian/src/Hadrian/Haskell/Cabal/Parse.hs#L116. Note that this is already wrong for stage 2 thereby preventing me from building Haddock >:(.

Still not ready. There is a problem with packageDbPath resolving to the wrong thing in some places. This stems from the fact that packageDbPath used to have a call to min in which clearly does the wrong thing and relies on the fact that we didn't used to build any libraries with the stage2 compiler. I haven't managed yet to work out how to precisely fix this though.

Thanks Andrey, I managed to apply your suggestions and things appear to work smoothly still. I'll try a clean rebuild overnight.

• Define and use stageLibaries
• Resolve some more stage confusion

Is there somewhere to view a rendered up-to-date copy of the documentation? If there's not then this doesn't seem like a great idea.

Thanks Alp, this will be useful. Please can we update the wiki page as well when this is merged.

CI passes: https://circleci.com/gh/ghc/ghc-diffs/1038

• Try to fix build ordering

I had a call with Simon and he suggested two changes which I have implemented now. The finaliser bug should also be fixed.

• Simplify
• Remove unused variable
• Remove extra arguments
• zonk after calling tcTopSpliceExpr
• Note and Richard's other comments
• Remove diff churn
• Remove blank line
• Remove blank line
• More formatting
• Store arguments to runTopSplice rather than whole TcM action
• Run and zonk finalisers

Updated with Ben's comments now.

• Address Ben's comments

The subprograms field has been removed. https://smlnj-gitlab.cs.uchicago.edu/manticore/llvm/commit/4eeaa0da042055b1cd17b339e2dde518a3026033

This still applies cleanly to master fwiw.

CI passes: https://circleci.com/gh/ghc/ghc/11719?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link

• fix test

• Stop infinite loop

Thanks @alpmestan

Still one problem with finalisers getting run in the wrong place.

• Remove blank line
• Remove blank line
• More formatting

• Simplify
• Remove unused variable
• Remove extra arguments
• zonk after calling tcTopSpliceExpr
• Remove merge artefact
• Note and Richard's other comments
• Remove diff churn

• zonk after calling tcTopSpliceExpr
• Remove merge artefact
• Note and Richard's other comments

If you look at the first version of this patch, I did as you suggested and persisted all the original parts but I think it was more complicated. You still need to persist TcLclEnv and so end up with an import cycle and several {-# SOURCE #-} imports in the zonker.

• Remove extra arguments

• Simplify
• Remove unused variable

• indentation
• Remove redundant conditional
• fix link

Thanks!

Would be good to land this still I think?

Probably still needs fixing but there appear to be no consumers for -ddump-json to care.

I think this was fixed in 954cbc7c106a20639960f55ebb85c5c972652d41

Looks plausible but I need to understand what Ben meant in his comment above before understanding the logic in detail.

Two comments.

Thanks @RolandSenn, do you need to change the title of the revision as well?

You could make the flag imply -fforce-recomp but if we don't understand how the patch works for the partial recompilation case then I would suggest that we don't understand what the code is doing well enough.

I removed that branch now I understand what is going on more.

• Remove redundant conditional

In D5287#145979, @bgamari wrote:

In order for this to affect the eventlog you will need to modify EventLog.c:postSchedEvent. However, it looks like info2 may already be used for something else in the EVENT_STOP_THREAD case (although it's not clear what).

The build works on hadrian but not on the old build system.

• Revert "Add dummy dependency on GHC.Types"

• Add dummy dependency on GHC.Types

• Add Simon's test as well

• Rename the spliced expression in the right context

• rebase

• indentation

Does this work when a module is not recompiled because it has not changed? In other words, what is the result of running ghc with this flag enabled twice in a row?

What is the problem with adding the plugin you want to load to the plugins field? There at least needs to be a comment explaining why it is necessary for these two different approaches which look very similar.