- Properly fix StaticPtr test fallout
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Nov 18 2018
- Fix StaticPtr testsuite fallout
- Add testsuite for Trac Trac #15633
Nov 17 2018
Oct 26 2018
Fix testsuite output for now inlined negateNatural worker
Aug 10 2018
- Correctly handle WayDyn in mkPluginUsage
- Correctly handle WayDyn in mkPluginUsage
Aug 9 2018
- Correctly handle WayDyn in mkPluginUsage
Aug 8 2018
Seems there’s another bug: https://ghc.haskell.org/trac/ghc/ticket/15492
Aug 7 2018
Use filterM and add tests
Aug 6 2018
@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.
Jul 19 2018
- Track object files of plugin in usages
Jul 18 2018
- Plugin dependency information is stored separately
- Track object files of plugin in usages
Jul 13 2018
- Plugin dependency information is stored separately
- Track object files of plugin in usages
Jul 10 2018
@mpickering @bgamari This patch is ready for review now
- Track object files of plugin in usages
- Track object files of plugin in usages
Jul 9 2018
- Plugin dependency information is stored separately
- Track object files of plugin in usages
Jul 6 2018
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.
Jul 5 2018
@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.
Jan 4 2018
May 2 2017
May 1 2017
This change removes the Eq instance for UniqSet: was this intentional? If so, why? If not, could this be added?
Feb 9 2017
- zonkCt tries to maintain the canonical form of a Ct.
- zonkCt tries to maintain the canonical form of a Ct.
Feb 8 2017
- 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
Feb 3 2017
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:
Oct 18 2016
Jan 4 2016
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.
Oct 27 2015
- -fno-strictness implies -fno-worker-wrapper
Oct 26 2015
- -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
Aug 1 2015
- 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
Jul 31 2015
- 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
Jul 30 2015
- Revert "Make -fcpr-off a dynamic flag"
- Second try: Make -fcpr-off a dynamic flag
Jul 29 2015
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?
May 28 2015
Yes, I'm happy that there a both the simple wrappers to create constraints, and a way to manipulate the EvBindsVar directly.
Apr 27 2015
Dec 1 2014
This makes ./configure go through on my machine now, where it didn't before this patch.