summaryrefslogtreecommitdiff
path: root/compiler
Commit message (Collapse)AuthorAgeFilesLines
...
* Use HsExpansion for overloaded list patternssheaf2021-06-2916-235/+414
| | | | Fixes #14380, #19997
* Demand: Better representation (#19050)Sebastian Graf2021-06-292-186/+351
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In #19050, we identified several ways in which we could make more illegal states irrepresentable. This patch introduces a few representation changes around `Demand` and `Card` with a better and earlier-failing API exported through pattern synonyms. Specifically, 1. The old enum definition of `Card` led to severely bloated code of operations on it. I switched to a bit vector representation; much nicer overall IMO. See Note [Bit vector representation for Card]. Most of the gripes with the old representation were related to where which kind of `Card` was allowed and the fact that it doesn't make sense for an absent or bottoming demand to carry a `SubDemand` that describes an evaluation context that is never realised. 2. So I refactored the `Demand` representation so that it has two new data constructors for `AbsDmd` and `BotDmd`. The old `(:*)` data constructor becomes a pattern synonym which expands absent demands as needed, so that it still forms a complete match and a versatile builder. The new `Demand` data constructor now carries a `CardNonAbs` and only occurs in a very limited number of internal call sites. 3. Wherever a full-blown `Card` might end up in a `CardNonAbs` field (like that of `D` or `Call`), I assert the consistency. When the smart builder of `(:*)` is called with an absent `Card`, I assert that the `SubDemand` is the same that we would expand to in the matcher. 4. `Poly` now takes a `CardNonOnce` and encodes the previously noticed invariant that we never produce `Poly C_11` or `Poly C_01`. I made sure that we never construct a `Poly` with `C_11` or `C_01`. Fixes #19050. We lose a tiny bit of anal perf overall, probably because the new `Demand` definition can't be unboxed. The biggest loser is WWRec, where allocations go from 16MB to 26MB in DmdAnal, making up for a total increase of (merely) 1.6%. It's all within acceptance thresholds. There are even two ghc/alloc metric decreases. T11545 decreases by *67%*! Metric Decrease: T11545 T18304
* Fix type and strictness signature of forkOn#Ryan Scott2021-06-281-1/+5
| | | | | | This is a follow-up to #19992, which fixes the type and strictness signature for `fork#`. The `forkOn#` primop also needs analogous changes, which this patch accomplishes.
* Try to simplify zoo of functions in `Tc.Utils.Monad`Alfredo Di Napoli2021-06-2848-788/+1259
| | | | | | | | | | | This commit tries to untangle the zoo of diagnostic-related functions in `Tc.Utils.Monad` so that we can have the interfaces mentions only `TcRnMessage`s while we push the creation of these messages upstream. It also ports TcRnMessage diagnostics to use the new API, in particular this commit switch to use TcRnMessage in the external interfaces of the diagnostic functions, and port the old SDoc to be wrapped into TcRnUnknownMessage.
* Revert "Make reallyUnsafePtrEquality# levity-polymorphic"Matthew Pickering2021-06-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | This reverts commit d1f59540e8b7be96b55ab4b286539a70bc75416c. This commit breaks the build of unordered-containers ``` [3 of 9] Compiling Data.HashMap.Internal.Array ( Data/HashMap/Internal/Array.hs, dist/build/Data/HashMap/Internal/Array.o, dist/build/Data/HashMap/Internal/Array.dyn_o ) *** Parser [Data.HashMap.Internal.Array]: Parser [Data.HashMap.Internal.Array]: alloc=21043544 time=13.621 *** Renamer/typechecker [Data.HashMap.Internal.Array]: Renamer/typechecker [Data.HashMap.Internal.Array]: alloc=151218672 time=187.083 *** Desugar [Data.HashMap.Internal.Array]: ghc: panic! (the 'impossible' happened) GHC version 9.3.20210625: expectJust splitFunTy CallStack (from HasCallStack): error, called at compiler/GHC/Data/Maybe.hs:68:27 in ghc:GHC.Data.Maybe expectJust, called at compiler/GHC/Core/Type.hs:1247:14 in ghc:GHC.Core.Type ``` Revert containers submodule update
* Inliner: Regard LitRubbish as TrivArg and not ConLikeSebastian Graf2021-06-272-2/+7
| | | | | | | | | | | | | | | | | | | | | | Part of fixing #19766 required the emission of `LitRubbish` as absent filler in places where we used `absentError` before. In WWRec we have the situation that such bindings occur in the argument to functions. With `LitRubbish` we inlined those functions, because 1. The absent binding was regarded as ConLike. So I fixed `exprIsHNFLike` to respond `False` to `LitRubbish`. 2. The other source of inlining was that after inlining such an absent binding, `LitRubbish` itself was regarded `ValueArg` by `interestingArg`, leading to more inlining. It now responds `TrivArg` to `LitRubbish`. Fixes #20035. There's one slight 1.6% ghc/alloc regression left in T15164 that is due to an additional specialisation `$s$cget`. I've no idea why that happens; the Core output before is identical and has the call site that we specialise for. Metric Decrease: WWRec
* WorkWrap: Make mkWWstr and mkWWcpr generate fewer let bindingsSebastian Graf2021-06-272-75/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5814#note_355144, Simon noted that `mkWWstr` and `mkWWcpr` could generate fewer let bindings and be implemented less indirectly by returning the rebuilt expressions directly, e.g. instead of ``` f :: (Int, Int) -> Int f (x, y) = x+y ==> f :: (Int, Int) -> Int f p = case p of (x, y) -> case x of I# x' -> case y of I# y' -> case $wf x' y' of r' -> let r = I# r' -- immediately returned in r f :: Int# -> Int# -> Int# $wf x' y' = let x = I# x' in -- only used in p let y = I# y' in -- only used in p let p = (x, y) in -- only used in the App below case (\(x,y) -> x+y) p of I# r' -> r' ``` we know generate ``` f :: (Int, Int) -> Int f p = case p of (x, y) -> case x of I# x' -> case y of I# y' -> case $wf x' y' of r' -> I# r' -- 1 fewer let f :: Int# -> Int# -> Int# $wf x' y' = case (\(x,y) -> x+y) (I# x, I# y) of I# r' -> -- 3 fewer lets r' ``` Which is much nicer and makes it easier to comprehend the output of worker-wrapper pre-Simplification as well as puts less strain on the Simplifier. I had to drop support for #18983, but we found that it's broken anyway. Simon is working on a patch that provides a bit more justification.
* WorkWrap: Remove mkWWargs (#19874)Sebastian Graf2021-06-272-195/+166
| | | | | | | | | | | | | | | | | | | | `mkWWargs`'s job was pushing casts inwards and doing eta expansion to match the arity with the number of argument demands we w/w for. Nowadays, we use the Simplifier to eta expand to arity. In fact, in recent years we have even seen the eta expansion done by w/w as harmful, see Note [Don't eta expand in w/w]. If a function hasn't enough manifest lambdas, don't w/w it! What purpose does `mkWWargs` serve in this world? Not a great one, it turns out! I could remove it by pulling some important bits, notably Note [Freshen WW arguments] and Note [Join points and beta-redexes]. Result: We reuse the freshened binder names of the wrapper in the worker where possible (see testuite changes), much nicer! In order to avoid scoping errors due to lambda-bound unfoldings in worker arguments, we zap those unfoldings now. In doing so, we fix #19766. Fixes #19874.
* Simplifier: Do Cast W/W for INLINE strong loop-breakersSebastian Graf2021-06-2714-59/+68
| | | | | | | | | | | | | | | | | | | | Strong loop-breakers never inline, INLINE pragma or not. Hence they should be treated as if there was no INLINE pragma on them. Also not doing Cast W/W for INLINE strong loop-breakers will trip up Strictness W/W, because it treats them as if there was no INLINE pragma. Subsequently, that will lead to a panic once Strictness W/W will no longer do eta-expansion, as we discovered while implementing !5814. I also renamed to `unfoldingInfo` to `realUnfoldingInfo` and redefined `unfoldingInfo` to zap the unfolding it returns in case of a strong loop-breaker. Now the naming and semantics is symmetrical to `idUnfolding`/`realIdUnfolding`. Now there was no more reason for `hasInlineUnfolding` to operate on `Id`, because the zapping of strong loop-breaker unfoldings moved from `idUnfolding` to `unfoldingInfo`, so I refactored it to take `IdInfo` and call it both from the Simplifier and WorkWrap, making it utterly clear that both checks are equivalent.
* Tc: Allow Typeable in quantified constraintsJakob Brünker2021-06-271-0/+1
| | | | | | | | | Previously, when using Typeable in a quantified constraint, GHC would complain that user-specified instances of Typeable aren't allowed. This was because checking for SigmaCtxt was missing from a check for whether an instance head is a hand-written binding. Fixes #20033
* codeGen: Fix header size for array write barriersGHC GitLab CI2021-06-261-3/+3
| | | | | | | | | Previously the code generator's logic for invoking the nonmoving write barrier was inconsistent with the write barrier itself. Namely, the code generator treated the header size argument as being in words whereas the barrier expected bytes. This was the cause of #19715. Fixes #19715.
* driver: Add implicit package dependencies for template-haskell packageMatthew Pickering2021-06-253-4/+21
| | | | | | | | | | | | | | | | | | | | | | | | | When TemplateHaskellQuotes is enabled, we also generate programs which mention symbols from the template-haskell module. So that package is added conditionally if the extension is turned on. We should really do the same for other wired-in packages: * base * ghc-bignum * ghc-prim * rts When we link an executable, we must also link against these libraries. In accordance with every other package, these dependencies should be added into the direct dependencies for a module automatically and end up in the interface file to record the fact the object file was created by linking against these packages. Unfortunately it is not so easy to work out when symbols from each of these libraries ends up in the generated program. You might think that `base` would always be used but the `ghc-prim` package doesn't depend on `base`, so you have to be a bit careful and this futher enhancement is left to a future patch.
* Suggest similar names when reporting types in terms (#19978)Vladislav Zavialov2021-06-251-25/+33
| | | | This fixes an error message regression.
* Make reallyUnsafePtrEquality# levity-polymorphicsheaf2021-06-251-1/+1
| | | | fixes #17126, updates containers submodule
* linker: Replace one missed usage of Opt_RPath with useXLinkerRPathMatthew Pickering2021-06-241-1/+1
| | | | Thanks to @wz1000 for spotting this oversight.
* Fixes around incomplete guards (#20023, #20024)Krzysztof Gogolewski2021-06-244-23/+14
| | | | | | | | | | - Fix linearity error with incomplete MultiWayIf (#20023) - Fix partial pattern binding error message (#20024) - Remove obsolete test LinearPolyTest It tested the special typing rule for ($), which was removed during the implementation of Quick Look 97cff9190d3. - Fix ticket numbers in linear/*/all.T, they referred to linear types issue tracker
* Fix desugaring with unboxed types (#19883)Krzysztof Gogolewski2021-06-241-1/+3
|
* Fix typo in Note [Quick Look for particular Ids]Viktor Dukhovni2021-06-231-1/+1
| | | | Fixes #20029
* [aarch64 NCG] Add better support for sub-word primopsMoritz Angermann2021-06-233-35/+150
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During the intial NCG development, GHC did not have support for anything below Words. As such the NCG didn't support any of this either. AArch64-Darwin however needs support for subword, as arguments in excess of the first eight (8) passed via registers are passed on the stack, and there in a packed fashion. Thus ghc learned about subword sizes. This than lead us to gain subword primops, and these subsequently highlighted deficiencies in the AArch64 NCG. This patch rectifies the ones I found through via the test-suite. I do not claim this to be exhaustive. Fixes: #19993 Metric Increase: T10421 T13035 T13719 T14697 T1969 T9203 T9872a T9872b T9872c T9872d T9961 haddock.Cabal haddock.base parsing001
* Converts diagnostics for two errors in Ghc.Tc.Module (#19926)Aaron Allen2021-06-233-7/+25
| | | | | | | | This adds constructors to TcRnMessage to replace use of TcRnUnknownMessage in Ghc.Tc.Module. Adds a test case for the UnsafeDueToPlugin warning. Closes #19926
* ghci: Correct free variable calculation in StgToByteCodeMatthew Pickering2021-06-233-8/+7
| | | | Fixes #20019
* Optimiser: Correctly deal with strings starting with unicode characters in ↵Matthew Pickering2021-06-231-21/+17
| | | | | | | | | | | | | | | | | | | | exprConApp_maybe For example: "\0" is encoded to "C0 80", then the rule would correct use a decoding function to work out the first character was "C0 80" but then just used BS.tail so the rest of the string was "80". This resulted in "\0" being transformed into '\C0\80' : unpackCStringUTF8# "80" Which is obviously bogus. I rewrote the function to call utf8UnconsByteString directly and avoid the roundtrip through Faststring so now the head/tail is computed by the same call. Fixes #19976
* Typos, minor comment fixesKrzysztof Gogolewski2021-06-2218-74/+34
| | | | | | | | | | | | | | | | | | | - Remove fstName, sndName, fstIdKey, sndIdKey - no longer used, removed from basicKnownKeyNames - Remove breakpointId, breakpointCondId, opaqueTyCon, unknownTyCon - they were used in the old implementation of the GHCi debugger - Fix typos in comments - Remove outdated comment in Lint.hs - Use 'LitRubbish' instead of 'RubbishLit' for consistency - Remove comment about subkinding - superseded by Note [Kind Constraint and kind Type] - Mention ticket ID in a linear types error message - Fix formatting in using-warnings.rst and linear-types.rst - Remove comment about 'Any' in Dynamic.hs - Dynamic now uses Typeable + existential instead of Any - Remove codeGen/should_compile/T13233.hs This was added by accident, it is not used and T13233 is already in should_fail
* Put tracing functions into their own moduleSylvain Henry2021-06-2258-492/+575
| | | | | | | | Now that Outputable is independent of DynFlags, we can put tracing functions using SDocs into their own module that doesn't transitively depend on any GHC.Driver.* module. A few modules needed to be moved to avoid loops in DEBUG mode.
* Linker/darwin: Properly honour -fno-use-rpathsMatthew Pickering2021-06-205-30/+43
| | | | | | | | | | | | | The specification is now simple * On linux, use `-Xlinker -rpath -Xlinker` to set the rpath of the executable * On darwin, never use `-Xlinker -rpath -Xlinker`, always inject the rpath afterwards, see `runInjectRPaths`. * If `-fno-use-rpaths` is passed then *never* inject anything into the rpath. Fixes #20004
* Set min LLVM version to 9 and make version checking use a non-inclusive upperZubin Duggal2021-06-203-14/+17
| | | | | | | bound. We use a non-inclusive upper bound so that setting the upper bound to 13 for example means that all 12.x versions are accepted.
* Simplify pprLHsContextRyan Scott2021-06-192-8/+22
| | | | | | | | | This removes an _ad hoc_ special case for empty `LHsContext`s in `pprLHsContext`, fixing #20011. To avoid regressions in pretty-printing data types and classes constructed via TH, we now apply a heuristic where we convert empty datatype contexts and superclasses to a `Nothing` (rather than `Just` an empty context). This will, for instance, avoid pretty-printing every TH-constructed data type as `data () => Blah ...`.
* Do not reassociate lexical negation (#19838)Vladislav Zavialov2021-06-192-8/+15
|
* Fix naturalToFloat/DoubleSylvain Henry2021-06-192-11/+39
| | | | | | | | | | | * move naturalToFloat/Double from ghc-bignum to base:GHC.Float and make them wired-in (as their integerToFloat/Double counterparts) * use the same rounding method as integerToFloat/Double. This is an oversight of 540fa6b2cff3802877ff56a47ab3611e33a9ac86 * add passthrough rules for intToFloat, intToDouble, wordToFloat, wordToDouble.
* Deprecate -Wmissing-monadfail-instances (#17875)Krzysztof Gogolewski2021-06-191-1/+2
| | | | | Also document deprecation of Wnoncanonical-monadfail-instances and -Wimplicit-kind-vars
* Fix type and strictness signature of fork#Simon Peyton Jones2021-06-191-1/+4
| | | | | | | | | | | When working eta-expansion and reduction, I found that fork# had a weaker strictness signature than it should have (#19992). In particular, it didn't record that it applies its argument exactly once. To this I needed to give it a proper type (its first argument is always a function, which in turn entailed a small change to the call in GHC.Conc.Sync This patch fixes it.
* Perf: fix appendFSSylvain Henry2021-06-191-2/+2
| | | | To append 2 FastString we don't need to convert them into ByteString: use ShortByteString's Semigroup instance instead.
* Add comments explaining why #19833 is wrongSimon Peyton Jones2021-06-191-36/+45
| | | | | I realised that the suggestion in #19833 doesn't work, and documented why in Note [Zapping Used Once info in WorkWrap]
* Improve pretty-printing of coercionsSimon Peyton Jones2021-06-181-1/+1
| | | | | | With -dsuppress-coercions, it's still good to be able to see the type of the coercion. This patch prints the type. Maybe we should have a flag to control this too.
* Improve abstractVars quantification orderingSimon Peyton Jones2021-06-181-5/+11
| | | | | | | | | | | | | | When floating a binding out past some type-variable binders, don't gratuitiously change the order of the binders. This small change gives code that is simpler, has less risk of non-determinism, and does not gratuitiously change type-variable order. See Note [Which type variables to abstract over] in GHC.Core.Opt.Simplify.Utils. This is really just refactoring; no change in behaviour.
* Enhance cast worker/wrapper for INLINABLESimon Peyton Jones2021-06-186-104/+220
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In #19890 we realised that cast worker/wrapper didn't really work properly for functions with an INLINABLE pragma, and hence a stable unfolding. This patch fixes the problem. Instead of disabling cast w/w when there is a stable unfolding (as we did before), we now tranfer the stable unfolding to the worker. It turned out that it was easier to do that if I moved the cast w/w stuff from prepareBinding to completeBind. No chnages at all in nofib results: -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- Min -0.0% 0.0% -63.8% -78.2% 0.0% Max -0.0% 0.0% +11.8% +11.7% 0.0% Geometric Mean -0.0% -0.0% -26.6% -33.4% -0.0% Small decreases in compile-time allocation for two tests (below) of around 2%. T12545 increased in compile-time alloc by 4%, but it's not reproducible on my machine, and is a known-wobbly test. Metric Increase: T12545 Metric Decrease: T18698a T18698b
* Fix error message for record updates, #19972Krzysztof Gogolewski2021-06-161-1/+1
| | | | Fix found by Adam Gundry.
* PPC NCG: Fix panic in linear register allocatorPeter Trommler2021-06-161-1/+1
|
* Remove the backend correction logic, as it is already been fixed at this pointDivam2021-06-161-27/+2
|
* profiling: Look in RHS of rules for cost centre ticksMatthew Pickering2021-06-165-52/+71
| | | | | | | | | | | | | | There are some obscure situations where the RHS of a rule can contain a tick which is not mentioned anywhere else in the program. If this happens you end up with an obscure linker error. The solution is quite simple, traverse the RHS of rules to also look for ticks. It turned out to be easier to implement if the traversal was moved into CoreTidy rather than at the start of code generation because there we still had easy access to the rules. ./StreamD.o(.text+0x1b9f2): error: undefined reference to 'StreamK_mkStreamFromStream_HPC_cc' ./MArray.o(.text+0xbe83): error: undefined reference to 'StreamK_mkStreamFromStream_HPC_cc' Main.o(.text+0x6fdb): error: undefined reference to 'StreamK_mkStreamFromStream_HPC_cc'
* HsUniToken and HsToken for HsArrow (#19623)Vladislav Zavialov2021-06-1621-80/+110
| | | | | | Another step towards a simpler design for exact printing. Updates the haddock submodule.
* DerivingVia for Hsc instances. GND for NonDetFastString and LexicalFastString.Baldur Blöndal2021-06-163-26/+13
|
* Fix INLINE pragmas in desugarerSimon Peyton Jones2021-06-102-31/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | In #19969 we discovered that GHC has has a bug *forever* that means it sometimes essentially discarded INLINE pragams. This happened when you have * Two more more mutually recursive functions * Some of which (presumably not all!) have an INLINE pragma * Completely monomorphic. This hits a particular case in GHC.HsToCore.Binds.dsAbsBinds, which was simply wrong -- it put the INLINE pragma on the wrong binder. This patch fixes the bug, rather easily, by adjusting the no-tyvar, no-dict case of GHC.HsToCore.Binds.dsAbsBinds. I also discovered that the GHC.Core.Opt.Pipeline.shortOutIndirections was not doing a good job for {-# INLINE lcl_id #-} lcl_id = BIG gbl_id = lcl_id Here we want to transfer the stable unfolding to gbl_id (we do), but we also want to remove it from lcl_id (we were not doing that). Otherwise both Ids have large stable unfoldings. Easily fixed. Note [Transferring IdInfo] explains.
* Reword: representation instead of levitysheaf2021-06-1044-259/+289
| | | | fixes #19756, updates haddock submodule
* Fix redundant importSylvain Henry2021-06-101-1/+2
|
* Do not add unfoldings to lambda-bindersSimon Peyton Jones2021-06-105-88/+23
| | | | | | | | | | | | | | | | | | For reasons described in GHC.Core.Opt.Simplify Historical Note [Case binders and join points], we used to keep a Core unfolding in one of the lambda-binders for a join point. But this was always a gross hack -- it's very odd to have an unfolding in a lambda binder, that refers to earlier lambda binders. The hack bit us in various ways: * Most seriously, it is incompatible with linear types in Core. * It complicated demand analysis, and could worsen results * It required extra care in the simplifier (simplLamBinder) * It complicated !5641 (look for "join binder unfoldings") So this patch just removes the hack. Happily, doind so turned out to have no effect on performance.
* FinderCache: Also cache file hashing in interface file checksMatthew Pickering2021-06-093-17/+39
| | | | | | | | | | Now that we hash object files to decide when to recompile due to TH, this can make a big difference as each interface file in a project will contain reference to the object files of all package dependencies. Especially when these are statically linked, hashing them can add up. The cache is invalidated when `depanalPartial` is called, like the normal finder cache.
* Introduce `hsExprType :: HsExpr GhcTc -> Type` in the new modulewip/hsExprTypeRyan Scott2021-06-0818-198/+363
| | | | | | | | | | | | | | | | | | | | | | | | | | | `GHC.Hs.Syn.Type` The existing `hsPatType`, `hsLPatType` and `hsLitType` functions have also been moved to this module This is a less ambitious take on the same problem that !2182 and !3866 attempt to solve. Rather than have the `hsExprType` function attempt to efficiently compute the `Type` of every subexpression in an `HsExpr`, this simply computes the overall `Type` of a single `HsExpr`. - Explicitly forbids the `SplicePat` `HsIPVar`, `HsBracket`, `HsRnBracketOut` and `HsTcBracketOut` constructors during the typechecking phase by using `Void` as the TTG extension field - Also introduces `dataConCantHappen` as a domain specific alternative to `absurd` to handle cases where the TTG extension points forbid a constructor. - Turns HIE file generation into a pure function that doesn't need access to the `DsM` monad to compute types, but uses `hsExprType` instead. - Computes a few more types during HIE file generation - Makes GHCi's `:set +c` command also use `hsExprType` instead of going through the desugarer to compute types. Updates haddock submodule Co-authored-by: Zubin Duggal <zubin.duggal@gmail.com>
* Parser: make less DynFlags dependentSylvain Henry2021-06-077-33/+42
| | | | | | | | | | This is an attempt at reducing the number of dependencies of the Parser (as reported by CountParserDeps). Modules in GHC.Parser.* don't import GHC.Driver.Session directly anymore. Sadly some GHC.Driver.* modules are still transitively imported and the number of dependencies didn't decrease. But it's a step in the right direction.
* Make Logger independent of DynFlagsSylvain Henry2021-06-0775-1299/+1306
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce LogFlags as a independent subset of DynFlags used for logging. As a consequence in many places we don't have to pass both Logger and DynFlags anymore. The main reason for this refactoring is that I want to refactor the systools interfaces: for now many systools functions use DynFlags both to use the Logger and to fetch their parameters (e.g. ldInputs for the linker). I'm interested in refactoring the way they fetch their parameters (i.e. use dedicated XxxOpts data types instead of DynFlags) for #19877. But if I did this refactoring before refactoring the Logger, we would have duplicate parameters (e.g. ldInputs from DynFlags and linkerInputs from LinkerOpts). Hence this patch first. Some flags don't really belong to LogFlags because they are subsystem specific (e.g. most DumpFlags). For example -ddump-asm should better be passed in NCGConfig somehow. This patch doesn't fix this tight coupling: the dump flags are part of the UI but they are passed all the way down for example to infer the file name for the dumps. Because LogFlags are a subset of the DynFlags, we must update the former when the latter changes (not so often). As a consequence we now use accessors to read/write DynFlags in HscEnv instead of using `hsc_dflags` directly. In the process I've also made some subsystems less dependent on DynFlags: - CmmToAsm: by passing some missing flags via NCGConfig (see new fields in GHC.CmmToAsm.Config) - Core.Opt.*: - by passing -dinline-check value into UnfoldingOpts - by fixing some Core passes interfaces (e.g. CallArity, FloatIn) that took DynFlags argument for no good reason. - as a side-effect GHC.Core.Opt.Pipeline.doCorePass is much less convoluted.