- May 31, 2019
-
-
[skip ci]
-
- May 30, 2019
-
-
For the reasons described in Note [residency] we run programs with -G1 when we care about the max_bytes_used metric.
-
-
As per @mpickering's suggestion on IRC this is to make the partial module-graph more easily accessible for API clients which don't intend to re-implementing depanal.
-
-
This changes the way preprocessor failures are presented to the user. Previously the user would simply get an unlocated message on stderr such as: `gcc' failed in phase `C pre-processor'. (Exit code: 1) Now at the problematic source file is mentioned: A.hs:1:1: error: `gcc' failed in phase `C pre-processor'. (Exit code: 1) This also makes live easier for GHC API clients as the preprocessor error is now thrown as a SourceError exception. -
This enables API clients to handle such errors instead of immideately crashing in the face of some kinds of user errors, which is arguably quite bad UX. Fixes #10887
-
This introduces a slight change of behaviour in the interrest of keeping the code simple: Previously summariseModule would not call addHomeModuleToFinder for summaries that are being re-used but now we do. We're forced to to do this in summariseFile because the file being summarised might not even be on the regular search path! So if GHC is to find it at all we have to pre-populate the cache with its location. For modules however the finder cache is really just a cache so we don't have to pre-populate it with the module's location. As straightforward as that seems I did almost manage to introduce a bug (or so I thought) because the call to addHomeModuleToFinder I copied from summariseFile used to use `ms_location old_summary` instead of the `location` argument to checkSummaryTimestamp. If this call were to overwrite the existing entry in the cache that would have resulted in us using the old location of any module even if it was, say, moved to a different directory between calls to 'depanal'. However it turns out the cache just ignores the location if the module is already in the cache. Since summariseModule has to search for the module, which has the side effect of populating the cache, everything would have been fine either way. Well I'm adding a test for this anyways: tests/depanal/OldModLocation.hs.
-
-
-
-
This is to enable #10887 as well as to make it possible to test downsweep on its own in the testsuite.
-
-
-
We are iterating through all object code for each heap objects when checking whether object code can be unloaded. For large projects in GHCi, this can be very expensive due to the large number of object code that needs to be loaded/unloaded. To speed it up, this arrangess all mapped sections of unloaded object code in a sorted array and use binary search to check if an address location fall on them.
-
As noted in #16701, it is possible that we will find that an object has no segments needing to be mapped. Previously this would result in mmap being called for a zero-length mapping, which would fail. We now simply skip the mmap call in this case; the rest of the logic just works.
-
In !980 Richard noted that he could not approve the MR. This mis-spelling was the reason. [skip ci]
-
Instead of trying to deduce which dynlibs are expected to be found (and then copied to the RTS's build dir) in libffi's build directory, with some OS specific logic, we now always just use `getDirectoryFilesIO` to look for those dynlibs and record their names in the manifest. The previous logic ended up causing problems on Windows, where we don't build dynlibs at all for now but the manifest file's logic didn't take that into account because it was only partially reproducing the criterions that determine whether or not we will be building shared libraries. This patch also re-enables the Hadrian/Windows CI job, which was failing to build GHC precisely because of libffi shared libraries and the aforementionned duplicated logic.
-
- May 29, 2019
-
-
[skip ci]
-
After the previous commit, `Settings` is just a thin wrapper around other groups of settings. While `Settings` is used by GHC-the-executable to initalize `DynFlags`, in principle another consumer of GHC-the-library could initialize `DynFlags` a different way. It therefore doesn't make sense for `DynFlags` itself (library code) to separate the settings that typically come from `Settings` from the settings that typically don't.
-
As far as I can tell, the fields within `Settings` aren't *intrinsicly* related. They just happen to be initialized the same way (in particular prior to the rest of `DynFlags`), and that is why they are grouped together. Within `Settings`, however, there are groups of settings that clearly do share something in common, regardless of how they anything is initialized. In the spirit of GHC being a library, where the end cosumer may choose to initialize this configuration in arbitrary ways, I made some new data types for thoses groups internal to `Settings`, and used them to define `Settings` instead. Hopefully this is a baby step towards a general decoupling of the stateful and stateless parts of GHC.
-
-
-
-
Currently 'getRootSummary' will fail with an exception if a 'TargetFile' is given but it does not exist even if an input buffer is passed along for this target. In this case it is not necessary for the file to exist since the buffer will be used as input for the compilation pipeline instead of the file anyways.
-
This allows GHC API clients, most notably tooling such as Haskell-IDE-Engine, to pass unsaved files to GHC more easily. Currently when targetContents is used but the module requires preprocessing 'preprocessFile' simply throws an error because the pipeline does not support passing a buffer. This change extends `runPipeline` to allow passing the input buffer into the pipeline. Before proceeding with the actual pipeline loop the input buffer is immediately written out to a new tempfile. I briefly considered refactoring the pipeline at large to pass around in-memory buffers instead of files, but this seems needlessly complicated since no pipeline stages other than Hsc could really support this at the moment.
-
-
-
Unboxed tuples and sums take extra RuntimeRep arguments, which must be manually passed in a few places. This was not done in deSugar/Check. This error was hidden because zipping functions in TyCoRep ignored lists with mismatching length. This is now fixed; the lengths are now checked by calling zipEqual. As suggested in #16565, I moved checking for isTyVar and isCoVar to zipTyEnv and zipCoEnv.
-
We fetch the ArgFlag for every argument by using splitForAllVarBndrs instead of splitForAllTys in unwrapTypeVars.
-
-
- short underline - :ghc-flag:, not :ghc-flags: - :since: have to be separate - newline before code block - workaround anchor generation so - pragma:SPECIALISE - pragma:SPECIALIZE-INLINE - pragma:SPECIALIZE-inline are different anchors, not all the same `pragma:SPECIALIZE` -
-
-
They are a particular type of perf tests. This patch introduces a 'stats_files_dir' configuration field in the testsuite driver where all haddock timing files (and possibly others in the future) are assumed to live. We also change both the Make and Hadrian build systems to pass respectively $(TOP)/testsuite/tests/perf/haddock/ and <build root>/stage1/haddock-timing-files/ as the value of that new configuration field, and to generate the timing files in those directories in the first place while generating documentation with haddock. This new test type can be seen as one dedicated to examining stats files that are generated while building a GHC distribution. This also lets us get rid of the 'extra_files' directives in the all.T entries for haddock.base, haddock.Cabal and haddock.compiler.
-
-
- May 28, 2019
-
-
- May 27, 2019
-
-
Previously -ddump-cmm was generating code with unbalanced curly braces: stg_atomically_entry() // [R1] { info_tbls: [(cfl, label: stg_atomically_info rep: tag:16 HeapRep 1 ptrs { Thunk } srt: Nothing)] stack_info: arg_space: 8 updfr_space: Just 8 } {offset cfl: // cfk unwind Sp = Just Sp + 0; _cfk::P64 = R1; //tick src<rts/PrimOps.cmm:(1243,1)-(1245,1)> R1 = I64[_cfk::P64 + 8 + 8 + 0 * 8]; call stg_atomicallyzh(R1) args: 8, res: 0, upd: 8; } }, <---- OPENING BRACE MISSING After this patch: stg_atomically_entry() { // [R1] <---- MISSING OPENING BRACE HERE { info_tbls: [(cfl, label: stg_atomically_info rep: tag:16 HeapRep 1 ptrs { Thunk } srt: Nothing)] stack_info: arg_space: 8 updfr_space: Just 8 } {offset cfl: // cfk unwind Sp = Just Sp + 0; _cfk::P64 = R1; //tick src<rts/PrimOps.cmm:(1243,1)-(1245,1)> R1 = I64[_cfk::P64 + 8 + 8 + 0 * 8]; call stg_atomicallyzh(R1) args: 8, res: 0, upd: 8; } }, -
-
When the number of entries of a cost centre reaches 11 digits, it takes up the whole space reserved for it and the prof file ends up looking like: ... no. entries %time %alloc %time %alloc ... ... 120918 978250 0.0 0.0 0.0 0.0 ... 118891 0 0.0 0.0 73.3 80.8 ... 11890229702412351 8.9 13.5 73.3 80.8 ... 118903 153799689 0.0 0.1 0.0 0.1 ... This results in tooling not being able to parse the .prof file. I realise we have the JSON output as well now, but still it'd be good to fix this little weirdness. Original bug report and full prof file can be seen here: <https://github.com/jaspervdj/profiteur/issues/28>.
-
