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.

Thanks a lot!

Thanks a lot Ryan.

In D5223#143889, @osa1 wrote:

What does it show if you print return value of getClosureData con? I'm asking because you don't know in this code that con points to a constructor without any indirections. For example, GHC can float con to the top-level and make it a CAF, in which case con might point to a IND_STATIC, not to a CONSTR_1_0.

We agreed at ICFP the best course of action was to patch the vector library.

I made some progress, it no longer prints out garbage but the result looks wrong.

• Correct the offset calculation, now working

What have you been able to implement with these extension points? The Hsc looks suspicious.

I was just suggest a comment indicating this future direction of travel not actually changing the existing patch. I don't know how this will impact code in the wild at all.

Much better than before.

In D5189#142767, @chessai wrote:

In D5189#142746, @mpickering wrote:

Thanks Daniel, can you clarify the difference between this patch and D5162?

I believe that D5162 only helps the situation with GHCi not having an implicit module Main(main) where, whereas this patch allows -main-is to specify an entry point to the program alternative to the name 'main' in the absence of a module header while compiling with ghc - the previous behaviour was to demand the existence of a function 'main'. If the explanation provided in docs/users_guide/bugs.rst is insuffient, please let me know.

Looks straightforward to me.

Thanks Daniel, can you clarify the difference between this patch and D5162?

The plugins have been unleashed.

Perhaps you should modify check_main instead to not look for main when loading a module into GHCi.

I chatted with Omer about this. Can you try the suggestion I left inline?

Seems like this patch would be a lot cleaner if a pattern synonym was defined for L. Having to use ViewPatterns everywhere is not very ergonomic.

This patch works for me.

I have tested that this patch fixes the panic.

Looks fine.

Thanks.

Any reason you can't put these functions in Haddock itself?

• Update for comments

• Suggestion