diff options
Diffstat (limited to 'compiler/coreSyn')
| -rw-r--r-- | compiler/coreSyn/CoreArity.hs | 16 | ||||
| -rw-r--r-- | compiler/coreSyn/CoreFVs.hs | 4 | ||||
| -rw-r--r-- | compiler/coreSyn/CoreLint.hs | 20 | ||||
| -rw-r--r-- | compiler/coreSyn/CoreMap.hs | 2 | ||||
| -rw-r--r-- | compiler/coreSyn/CoreOpt.hs | 12 | ||||
| -rw-r--r-- | compiler/coreSyn/CorePrep.hs | 8 | ||||
| -rw-r--r-- | compiler/coreSyn/CoreSubst.hs | 2 | ||||
| -rw-r--r-- | compiler/coreSyn/CoreSyn.hs | 18 | ||||
| -rw-r--r-- | compiler/coreSyn/CoreUnfold.hs | 14 | ||||
| -rw-r--r-- | compiler/coreSyn/CoreUtils.hs | 32 | ||||
| -rw-r--r-- | compiler/coreSyn/MkCore.hs | 2 |
11 files changed, 65 insertions, 65 deletions
diff --git a/compiler/coreSyn/CoreArity.hs b/compiler/coreSyn/CoreArity.hs index afd6759571..5f7f5593ba 100644 --- a/compiler/coreSyn/CoreArity.hs +++ b/compiler/coreSyn/CoreArity.hs @@ -220,7 +220,7 @@ Now suppose we have: Now we want the built-in op/$dfList rule will fire to give blah = $copList dCInt -But with eta-expansion 'blah' might (and in Trac #3772, which is +But with eta-expansion 'blah' might (and in #3772, which is slightly more complicated, does) turn into blah = op (\eta. ($dfList dCInt |> sym co) eta) @@ -302,7 +302,7 @@ This isn't really right in the presence of seq. Consider This should diverge! But if we eta-expand, it won't. We ignore this "problem" (unless -fpedantic-bottoms is on), because being scrupulous would lose an important transformation for many programs. (See -Trac #5587 for an example.) +#5587 for an example.) Consider also f = \x -> error "foo" @@ -322,7 +322,7 @@ this transformation. So we try to limit it as much as possible: (1) Do NOT move a lambda outside a known-bottom case expression case undefined of { (a,b) -> \y -> e } - This showed up in Trac #5557 + This showed up in #5557 (2) Do NOT move a lambda outside a case if all the branches of the case are known to return bottom. @@ -334,7 +334,7 @@ this transformation. So we try to limit it as much as possible: (3) Do NOT move a lambda outside a case unless (a) The scrutinee is ok-for-speculation, or (b) more liberally: the scrutinee is cheap (e.g. a variable), and - -fpedantic-bottoms is not enforced (see Trac #2915 for an example) + -fpedantic-bottoms is not enforced (see #2915 for an example) Of course both (1) and (2) are readily defeated by disguising the bottoms. @@ -381,7 +381,7 @@ See also Id.isOneShotBndr. Note [State hack and bottoming functions] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It's a terrible idea to use the state hack on a bottoming function. -Here's what happens (Trac #2861): +Here's what happens (#2861): f :: String -> IO T f = \p. error "..." @@ -410,7 +410,7 @@ Extrude g1.g3 And now we can repeat the whole loop. Aargh! The bug is in applying the state hack to a function which then swallows the argument. -This arose in another guise in Trac #3959. Here we had +This arose in another guise in #3959. Here we had catch# (throw exn >> return ()) @@ -590,7 +590,7 @@ says it has arity "infinity" the first time round. This example happens a lot; it first showed up in Andy Gill's thesis, fifteen years ago! It also shows up in the code for 'rnf' on lists -in Trac #4138. +in #4138. The analysis is easy to achieve because exprEtaExpandArity takes an argument @@ -726,7 +726,7 @@ arityType env (Cast e co) -- See Note [exprArity invariant] (2); must be true of -- arityType too, since that is how we compute the arity -- of variables, and they in turn affect result of exprArity - -- Trac #5441 is a nice demo + -- #5441 is a nice demo -- However, do make sure that ATop -> ATop and ABot -> ABot! -- Casts don't affect that part. Getting this wrong provoked #5475 diff --git a/compiler/coreSyn/CoreFVs.hs b/compiler/coreSyn/CoreFVs.hs index 18e109a745..4674b21978 100644 --- a/compiler/coreSyn/CoreFVs.hs +++ b/compiler/coreSyn/CoreFVs.hs @@ -346,14 +346,14 @@ orphNamesOfTyCon tycon = unitNameSet (getName tycon) `unionNameSet` case tyConCl orphNamesOfType :: Type -> NameSet orphNamesOfType ty | Just ty' <- coreView ty = orphNamesOfType ty' - -- Look through type synonyms (Trac #4912) + -- Look through type synonyms (#4912) orphNamesOfType (TyVarTy _) = emptyNameSet orphNamesOfType (LitTy {}) = emptyNameSet orphNamesOfType (TyConApp tycon tys) = orphNamesOfTyCon tycon `unionNameSet` orphNamesOfTypes tys orphNamesOfType (ForAllTy bndr res) = orphNamesOfType (binderType bndr) `unionNameSet` orphNamesOfType res -orphNamesOfType (FunTy _ arg res) = unitNameSet funTyConName -- NB! See Trac #8535 +orphNamesOfType (FunTy _ arg res) = unitNameSet funTyConName -- NB! See #8535 `unionNameSet` orphNamesOfType arg `unionNameSet` orphNamesOfType res orphNamesOfType (AppTy fun arg) = orphNamesOfType fun `unionNameSet` orphNamesOfType arg diff --git a/compiler/coreSyn/CoreLint.hs b/compiler/coreSyn/CoreLint.hs index 62ddb9f410..c29c113b54 100644 --- a/compiler/coreSyn/CoreLint.hs +++ b/compiler/coreSyn/CoreLint.hs @@ -373,7 +373,7 @@ interactiveInScope :: HscEnv -> [Var] -- When we are not in GHCi, the interactive context (hsc_IC hsc_env) is empty -- so this is a (cheap) no-op. -- --- See Trac #8215 for an example +-- See #8215 for an example interactiveInScope hsc_env = tyvars ++ ids where @@ -806,7 +806,7 @@ lintCoreExpr e@(Case scrut var alt_ty alts) = ; checkL (not $ isFloatingTy scrut_ty && any isLitPat alts) (ptext (sLit $ "Lint warning: Scrutinising floating-point " ++ "expression with literal pattern in case " ++ - "analysis (see Trac #9238).") + "analysis (see #9238).") $$ text "scrut" <+> ppr scrut) ; case tyConAppTyCon_maybe (idType var) of @@ -927,7 +927,7 @@ checkJoinOcc var n_args Note [No alternatives lint check] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Case expressions with no alternatives are odd beasts, and it would seem -like they would worth be looking at in the linter (cf Trac #10180). We +like they would worth be looking at in the linter (cf #10180). We used to check two things: * exprIsHNF is false: it would *seem* to be terribly wrong if @@ -937,7 +937,7 @@ used to check two things: scrutinee is diverging for sure. It was already known that the second test was not entirely reliable. -Unfortunately (Trac #13990), the first test turned out not to be reliable +Unfortunately (#13990), the first test turned out not to be reliable either. Getting the checks right turns out to be somewhat complicated. For example, suppose we have (comment 8) @@ -1395,7 +1395,7 @@ lintType (CoercionTy co) {- Note [Stupid type synonyms] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Consider (Trac #14939) +Consider (#14939) type Alg cls ob = ob f :: forall (cls :: * -> Constraint) (b :: Alg cls *). b @@ -1572,18 +1572,18 @@ lintCoreRule fun fun_ty rule@(Rule { ru_name = name, ru_bndrs = bndrs It's very bad if simplifying a rule means that one of the template variables (ru_bndrs) that /is/ mentioned on the RHS becomes not-mentioned in the LHS (ru_args). How can that happen? Well, in -Trac #10602, SpecConstr stupidly constructed a rule like +#10602, SpecConstr stupidly constructed a rule like forall x,c1,c2. f (x |> c1 |> c2) = .... But simplExpr collapses those coercions into one. (Indeed in -Trac #10602, it collapsed to the identity and was removed altogether.) +#10602, it collapsed to the identity and was removed altogether.) We don't have a great story for what to do here, but at least this check will nail it. -NB (Trac #11643): it's possible that a variable listed in the +NB (#11643): it's possible that a variable listed in the binders becomes not-mentioned on both LHS and RHS. Here's a silly example: RULE forall x y. f (g x y) = g (x+1) (y-1) @@ -2088,7 +2088,7 @@ type WarnsAndErrs = (Bag MsgDoc, Bag MsgDoc) {- Note [Checking for global Ids] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Before CoreTidy, all locally-bound Ids must be LocalIds, even -top-level ones. See Note [Exported LocalIds] and Trac #9857. +top-level ones. See Note [Exported LocalIds] and #9857. Note [Checking StaticPtrs] ~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -2124,7 +2124,7 @@ Note [Linting type synonym applications] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When linting a type-synonym, or type-family, application S ty1 .. tyn -we behave as follows (Trac #15057, #T15664): +we behave as follows (#15057, #T15664): * If lf_report_unsat_syns = True, and S has arity < n, complain about an unsaturated type synonym or type family diff --git a/compiler/coreSyn/CoreMap.hs b/compiler/coreSyn/CoreMap.hs index 3d0693466a..d50dcbf1bc 100644 --- a/compiler/coreSyn/CoreMap.hs +++ b/compiler/coreSyn/CoreMap.hs @@ -133,7 +133,7 @@ Note [Empty case alternatives] * For a key (Case e b ty []) we MUST look at the return type 'ty', because otherwise (Case (error () "urk") _ Int []) would compare equal to (Case (error () "urk") _ Bool []) - which is utterly wrong (Trac #6097) + which is utterly wrong (#6097) We could compare the return type regardless, but the wildly common case is that it's unnecessary, so we have two fields (cm_case and cm_ecase) diff --git a/compiler/coreSyn/CoreOpt.hs b/compiler/coreSyn/CoreOpt.hs index d0dba81e3e..0f7f5fbf20 100644 --- a/compiler/coreSyn/CoreOpt.hs +++ b/compiler/coreSyn/CoreOpt.hs @@ -312,7 +312,7 @@ simple_app env (Tick t e) as -- The let might appear there as a result of inlining -- e.g. let f = let x = e in b -- in f a1 a2 --- (Trac #13208) +-- (#13208) simple_app env (Let bind body) as = case simple_opt_bind env bind of (env', Nothing) -> simple_app env' body as @@ -490,7 +490,7 @@ rhss here. Note [Preserve join-binding arity] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Be careful /not/ to eta-reduce the RHS of a join point, lest we lose -the join-point arity invariant. Trac #15108 was caused by simplifying +the join-point arity invariant. #15108 was caused by simplifying the RHS with simple_opt_expr, which does eta-reduction. Solution: simplify the RHS of a join point by simplifying under the lambdas (which of course should be there). @@ -710,7 +710,7 @@ A more common case is when f = \x. error ".." -and again its arity increses (Trac #15517) +and again its arity increses (#15517) -} {- ********************************************************************* @@ -759,7 +759,7 @@ dealWithStringLiteral. Note [Push coercions in exprIsConApp_maybe] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -In Trac #13025 I found a case where we had +In #13025 I found a case where we had op (df @t1 @t2) -- op is a ClassOp where df = (/\a b. K e1 e2) |> g @@ -1181,7 +1181,7 @@ pushCoTyArg :: CoercionR -> Type -> Maybe (Type, MCoercionR) -- it's faster not to compute it, though. pushCoTyArg co ty -- The following is inefficient - don't do `eqType` here, the coercion - -- optimizer will take care of it. See Trac #14737. + -- optimizer will take care of it. See #14737. -- -- | tyL `eqType` tyR -- -- = Just (ty, Nothing) @@ -1219,7 +1219,7 @@ pushCoValArg :: CoercionR -> Maybe (Coercion, MCoercion) -- the returned coercion would have been reflexive. pushCoValArg co -- The following is inefficient - don't do `eqType` here, the coercion - -- optimizer will take care of it. See Trac #14737. + -- optimizer will take care of it. See #14737. -- -- | tyL `eqType` tyR -- -- = Just (mkRepReflCo arg, Nothing) diff --git a/compiler/coreSyn/CorePrep.hs b/compiler/coreSyn/CorePrep.hs index cf37a8d93b..bf6182bc89 100644 --- a/compiler/coreSyn/CorePrep.hs +++ b/compiler/coreSyn/CorePrep.hs @@ -344,7 +344,7 @@ partial applications. But it's easier to let them through. Note [Dead code in CorePrep] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Imagine that we got an input program like this (see Trac #4962): +Imagine that we got an input program like this (see #4962): f :: Show b => Int -> (Int, b -> Maybe Int -> Int) f x = (g True (Just x) + g () (Just x), g) @@ -790,7 +790,7 @@ data ArgInfo = CpeApp CoreArg ~~~~~~~~~~~~~~~~~~~ If we got, say runRW# (case bot of {}) -which happened in Trac #11291, we do /not/ want to turn it into +which happened in #11291, we do /not/ want to turn it into (case bot of {}) realWorldPrimId# because that gives a panic in CoreToStg.myCollectArgs, which expects only variables in function position. But if we are sure to make @@ -1051,7 +1051,7 @@ Note [Floating unlifted arguments] Consider C (let v* = expensive in v) where the "*" indicates "will be demanded". Usually v will have been -inlined by now, but let's suppose it hasn't (see Trac #2756). Then we +inlined by now, but let's suppose it hasn't (see #2756). Then we do *not* want to get let v* = expensive in C v @@ -1183,7 +1183,7 @@ tryEtaReducePrep bndrs (Let bind@(NonRec _ r) body) -- Otherwise we risk reducing -- \x. (Tick (Breakpoint {x}) f x) -- ==> Tick (breakpoint {x}) f --- which is bogus (Trac #17228) +-- which is bogus (#17228) -- tryEtaReducePrep bndrs (Tick tickish e) -- = fmap (mkTick tickish) $ tryEtaReducePrep bndrs e diff --git a/compiler/coreSyn/CoreSubst.hs b/compiler/coreSyn/CoreSubst.hs index 2df3fb1b52..8ba2e68446 100644 --- a/compiler/coreSyn/CoreSubst.hs +++ b/compiler/coreSyn/CoreSubst.hs @@ -718,7 +718,7 @@ substTickish _subst other = other The functions that substitute over IdInfo must be pretty lazy, because they are knot-tied by substRecBndrs. -One case in point was Trac #10627 in which a rule for a function 'f' +One case in point was #10627 in which a rule for a function 'f' referred to 'f' (at a different type) on the RHS. But instead of just substituting in the rhs of the rule, we were calling simpleOptExpr, which looked at the idInfo for 'f'; result <<loop>>. diff --git a/compiler/coreSyn/CoreSyn.hs b/compiler/coreSyn/CoreSyn.hs index c4fedbbad7..f48fef568e 100644 --- a/compiler/coreSyn/CoreSyn.hs +++ b/compiler/coreSyn/CoreSyn.hs @@ -233,7 +233,7 @@ These data types are the heart of the compiler -- can't be @Red@ at that program point. -- -- 5. Floating-point values must not be scrutinised against literals. --- See Trac #9238 and Note [Rules for floating-point comparisons] +-- See #9238 and Note [Rules for floating-point comparisons] -- in PrelRules for rationale. -- -- * Cast an expression to a particular type. @@ -338,7 +338,7 @@ Note [Literal alternatives] Literal alternatives (LitAlt lit) are always for *un-lifted* literals. We have one literal, a literal Integer, that is lifted, and we don't allow in a LitAlt, because LitAlt cases don't do any evaluation. Also -(see Trac #5603) if you say +(see #5603) if you say case 3 of S# x -> ... J# _ _ -> ... @@ -348,7 +348,7 @@ literals are an opaque encoding of an algebraic data type, not of an unlifted literal, like all the others. Also, we do not permit case analysis with literal patterns on floating-point -types. See Trac #9238 and Note [Rules for floating-point comparisons] in +types. See #9238 and Note [Rules for floating-point comparisons] in PrelRules for the rationale for this restriction. -------------------------- CoreSyn INVARIANTS --------------------------- @@ -386,7 +386,7 @@ Consider, In order to be able to inline `f`, we would like to float `a` to the top. Another option would be to inline `a`, but that would lead to duplicating string -literals, which we want to avoid. See Trac #8472. +literals, which we want to avoid. See #8472. The solution is simply to allow top-level unlifted binders. We can't allow arbitrary unlifted expression at the top-level though, unlifted binders cannot @@ -395,7 +395,7 @@ be thunks, so we just allow string literals. We allow the top-level primitive string literals to be wrapped in Ticks in the same way they can be wrapped when nested in an expression. CoreToSTG currently discards Ticks around top-level primitive string literals. -See Trac #14779. +See #14779. Also see Note [Compilation plan for top-level string literals]. @@ -518,7 +518,7 @@ this exhaustive list can be empty! we do NOT want to replace case (x::T) of Bool {} --> error Bool "Inaccessible case" because x might raise an exception, and *that*'s what we want to see! - (Trac #6067 is an example.) To preserve semantics we'd have to say + (#6067 is an example.) To preserve semantics we'd have to say x `seq` error Bool "Inaccessible case" but the 'seq' is just a case, so we are back to square 1. Or I suppose we could say @@ -626,7 +626,7 @@ However, join points have simpler invariants in other ways 6. A join point can have a levity-polymorphic RHS e.g. let j :: r :: TYPE l = fail void# in ... - This happened in an intermediate program Trac #13394 + This happened in an intermediate program #13394 Examples: @@ -1113,7 +1113,7 @@ chooseOrphanAnchor :: NameSet -> IsOrphan -- Something (rule, instance) is relate to all the Names in this -- list. Choose one of them to be an "anchor" for the orphan. We make -- the choice deterministic to avoid gratuitious changes in the ABI --- hash (Trac #4012). Specifically, use lexicographic comparison of +-- hash (#4012). Specifically, use lexicographic comparison of -- OccName rather than comparing Uniques -- -- NB: 'minimum' use Ord, and (Ord OccName) works lexicographically @@ -1641,7 +1641,7 @@ ones are OtherCon {} If we know this binder (say a lambda binder) will be bound to an evaluated thing, we want to retain that - info in simpleOptExpr; see Trac #13077. + info in simpleOptExpr; see #13077. We consider even a StableUnfolding as fragile, because it needs substitution. diff --git a/compiler/coreSyn/CoreUnfold.hs b/compiler/coreSyn/CoreUnfold.hs index e55e12487b..1e4e39e289 100644 --- a/compiler/coreSyn/CoreUnfold.hs +++ b/compiler/coreSyn/CoreUnfold.hs @@ -260,7 +260,7 @@ the `UnfoldingGuidance`.) In the example, x's ug_arity is 0, so we should inline it at every use site. It's rare to have such an INLINE pragma (usually INLINE Is on -functions), but it's occasionally very important (Trac #15578, #15519). +functions), but it's occasionally very important (#15578, #15519). In #15519 we had something like x = case (g a b) of I# r -> T r {-# INLINE x #-} @@ -357,7 +357,7 @@ But given this decision it's vital that we do where g* is (for some strange reason) the loop breaker. If we don't occ-anal it when reading it in, we won't mark g as a loop breaker, and we may inline g entirely in body, dropping its binding, and leaving -the occurrence in f out of scope. This happened in Trac #8892, where +the occurrence in f out of scope. This happened in #8892, where the unfolding in question was a DFun unfolding. But more generally, the simplifier is designed on the @@ -395,7 +395,7 @@ GlobalIds. That seems (just) tolerable for the occurrence analysis that happens just before the Simplifier, but not for unfoldings, which are Linted independently. As a quick workaround, we disable binder swap in this module. -See Trac #16288 and #16296 for further plans. +See #16288 and #16296 for further plans. Note [Calculate unfolding guidance on the non-occ-anal'd expression] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -910,7 +910,7 @@ Simon M tried a MUCH bigger discount: (10 * (10 + n_val_args)), and said it was an "unambiguous win", but its terribly dangerous because a function with many many case branches, each finishing with a constructor, can have an arbitrarily large discount. This led to -terrible code bloat: see Trac #6099. +terrible code bloat: see #6099. Note [Unboxed tuple size and result discount] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -936,10 +936,10 @@ monadic combinators with continuation arguments, where inlining is quite important. But we don't want a big discount when a function is called many times -(see the detailed comments with Trac #6048) because if the function is +(see the detailed comments with #6048) because if the function is big it won't be inlined at its many call sites and no benefit results. Indeed, we can get exponentially big inlinings this way; that is what -Trac #6048 is about. +#6048 is about. On the other hand, for data-valued arguments, if there are lots of case expressions in the body, each one will get smaller if we apply @@ -1170,7 +1170,7 @@ certainlyWillInline dflags fn_info ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Don't claim that thunks will certainly inline, because that risks work duplication. Even if the work duplication is not great (eg is_cheap -holds), it can make a big difference in an inner loop In Trac #5623 we +holds), it can make a big difference in an inner loop In #5623 we found that the WorkWrap phase thought that y = case x of F# v -> F# (v +# v) was certainlyWillInline, so the addition got duplicated. diff --git a/compiler/coreSyn/CoreUtils.hs b/compiler/coreSyn/CoreUtils.hs index 5b161995ea..8e298adf6a 100644 --- a/compiler/coreSyn/CoreUtils.hs +++ b/compiler/coreSyn/CoreUtils.hs @@ -190,7 +190,7 @@ not much used, except in the output of the desugarer. Example: let a = Int in (\x:a. x) Given this, exprType must be careful to substitute 'a' in the -result type (Trac #8522). +result type (#8522). Note [Existential variables and silly type synonyms] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -202,7 +202,7 @@ Consider Now, the type of 'x' is (Funny a), where 'a' is existentially quantified. That means that 'exprType' and 'coreAltsType' may give a result that *appears* -to mention an out-of-scope type variable. See Trac #3409 for a more real-world +to mention an out-of-scope type variable. See #3409 for a more real-world example. Various possibilities suggest themselves: @@ -571,7 +571,7 @@ that cannot match. For example: Suppose that for some silly reason, x isn't substituted in the case expression. (Perhaps there's a NOINLINE on it, or profiling SCC stuff -gets in the way; cf Trac #3118.) Then the full-lazines pass might produce +gets in the way; cf #3118.) Then the full-lazines pass might produce this x = Red @@ -827,11 +827,11 @@ and similarly in cascade for all the join points! NB: it's important that all this is done in [InAlt], *before* we work on the alternatives themselves, because Simplify.simplAlt may zap the occurrence info on the binders in the alternatives, which in turn -defeats combineIdenticalAlts (see Trac #7360). +defeats combineIdenticalAlts (see #7360). Note [Care with impossible-constructors when combining alternatives] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Suppose we have (Trac #10538) +Suppose we have (#10538) data T = A | B | C | D case x::T of (Imposs-default-cons {A,B}) @@ -867,7 +867,7 @@ Then when combining the A and C alternatives we get Note that we have a new DEFAULT branch that we didn't have before. So we need delete from the "impossible-default-constructors" all the -known-con alternatives that we have eliminated. (In Trac #11172 we +known-con alternatives that we have eliminated. (In #11172 we missed the first one.) -} @@ -950,7 +950,7 @@ it as trivial we may land up with let-bindings like let v = case x of {} in ... and after CoreToSTG that gives let v = x in ... -and that confuses the code generator (Trac #11155). So best to kill +and that confuses the code generator (#11155). So best to kill it off at source. -} @@ -1102,7 +1102,7 @@ dupAppSize :: Int dupAppSize = 8 -- Size of term we are prepared to duplicate -- This is *just* big enough to make test MethSharing -- inline enough join points. Really it should be - -- smaller, and could be if we fixed Trac #4960. + -- smaller, and could be if we fixed #4960. {- ************************************************************************ @@ -1116,7 +1116,7 @@ Note [exprIsWorkFree] exprIsWorkFree is used when deciding whether to inline something; we don't inline it if doing so might duplicate work, by peeling off a complete copy of the expression. Here we do not want even to -duplicate a primop (Trac #5623): +duplicate a primop (#5623): eg let x = a #+ b in x +# x we do not want to inline/duplicate x @@ -1276,7 +1276,7 @@ expansion. Specifically: * False of case-expressions. If we have let x = case ... in ...(case x of ...)... - we won't simplify. We have to inline x. See Trac #14688. + we won't simplify. We have to inline x. See #14688. * False of let-expressions (same reason); and in any case we float lets out of an RHS if doing so will reveal an expandable @@ -1657,7 +1657,7 @@ But we restrict it sharply: add unlifted algebraic types in due course. ------ Historical note: Trac #15696: -------- +----- Historical note: #15696: -------- Previously SetLevels used exprOkForSpeculation to guide floating of single-alternative cases; it now uses exprIsHNF Note [Floating single-alternative cases]. @@ -1676,9 +1676,9 @@ But we restrict it sharply: ...(case x of y A -> ... _ -> ...blah...)... - which is utterly bogus (seg fault); see Trac #5453. + which is utterly bogus (seg fault); see #5453. ------ Historical note: Trac #3717: -------- +----- Historical note: #3717: -------- foo :: Int -> Int foo 0 = 0 foo n = (if n < 5 then 1 else 2) `seq` foo (n-1) @@ -1703,7 +1703,7 @@ points do the job nicely. Note [Primops with lifted arguments] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Is this ok-for-speculation (see Trac #13027)? +Is this ok-for-speculation (see #13027)? reallyUnsafePtrEq# a b Well, yes. The primop accepts lifted arguments and does not evaluate them. Indeed, in general primops are, well, primitive @@ -2279,7 +2279,7 @@ There are some particularly delicate points here: *keeps* arity 1 (perhaps also wrongly). So CorePrep eta-expands the definition again, so that it does not termninate after all. Result: seg-fault because the boolean case actually gets a function value. - See Trac #1947. + See #1947. So it's important to do the right thing. @@ -2434,7 +2434,7 @@ to the rule that * f is not bottom we can eta-reduce \x. f x ===> f -This turned up in Trac #7542. +This turned up in #7542. ************************************************************************ diff --git a/compiler/coreSyn/MkCore.hs b/compiler/coreSyn/MkCore.hs index 999cfc7db5..f9609f834d 100644 --- a/compiler/coreSyn/MkCore.hs +++ b/compiler/coreSyn/MkCore.hs @@ -840,7 +840,7 @@ used, and does a w/w split thus After some simplification, the (absentError "blah") thunk goes away. ------ Tricky wrinkle ------- -Trac #14285 had, roughly +#14285 had, roughly data T a = MkT a !a {-# INLINABLE f #-} |