Commit 610ec224 authored by Ryan Scott's avatar Ryan Scott Committed by Marge Bot

Update Trac ticket URLs to point to GitLab

This moves all URL references to Trac tickets to their corresponding
GitLab counterparts.
parent afc80730
Pipeline #3547 passed with stages
in 359 minutes and 48 seconds
...@@ -8,9 +8,9 @@ information to help you get started right away. ...@@ -8,9 +8,9 @@ information to help you get started right away.
The GHC Developer's Wiki The GHC Developer's Wiki
======================== ========================
The home for GHC hackers is our Trac instance, located here: The home for GHC hackers is our GitLab instance, located here:
<http://ghc.haskell.org/trac/ghc> <https://gitlab.haskell.org/ghc/ghc>
From here, you can file bugs (or look them up,) use the wiki, view the From here, you can file bugs (or look them up,) use the wiki, view the
`git` history, among other things. Of particular note is the building `git` history, among other things. Of particular note is the building
...@@ -64,8 +64,8 @@ Now, hack on your copy and rebuild (with `make`) as necessary. ...@@ -64,8 +64,8 @@ Now, hack on your copy and rebuild (with `make`) as necessary.
Then start by making your commits however you want. When you're done, you can submit Then start by making your commits however you want. When you're done, you can submit
a pull request on Github for small changes. For larger changes the patch needs to be a pull request on Github for small changes. For larger changes the patch needs to be
submitted to [Phabricator](https://phabricator.haskell.org/) for code review. submitted to [Phabricator](https://phabricator.haskell.org/) for code review.
The GHC Trac Wiki has a good summary for the [overall process](https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/FixingBugs) The GHC Wiki has a good summary for the [overall process](https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/FixingBugs)
as well as a guide on as well as a guide on
[how to use Phabricator/arcanist](https://ghc.haskell.org/trac/ghc/wiki/Phabricator). [how to use Phabricator/arcanist](https://ghc.haskell.org/trac/ghc/wiki/Phabricator).
......
...@@ -22,7 +22,7 @@ MAKEFLAGS += --no-builtin-rules ...@@ -22,7 +22,7 @@ MAKEFLAGS += --no-builtin-rules
# ----------------------------------------------------------------------------- # -----------------------------------------------------------------------------
# Sanitize environment # Sanitize environment
# See Trac #11530 # See #11530
export GREP_OPTIONS := export GREP_OPTIONS :=
ifneq "$(filter maintainer-clean distclean clean clean_% help,$(MAKECMDGOALS))" "" ifneq "$(filter maintainer-clean distclean clean clean_% help,$(MAKECMDGOALS))" ""
......
...@@ -8,7 +8,7 @@ environment for the Haskell functional programming language. ...@@ -8,7 +8,7 @@ environment for the Haskell functional programming language.
For more information, visit [GHC's web site][1]. For more information, visit [GHC's web site][1].
Information for developers of GHC can be found on the [GHC Trac][2]. Information for developers of GHC can be found on the [GHC issue tracker][2].
Getting the Source Getting the Source
......
...@@ -1483,7 +1483,7 @@ AC_SUBST([GhcPkgCmd]) ...@@ -1483,7 +1483,7 @@ AC_SUBST([GhcPkgCmd])
# to compile .hc code. # to compile .hc code.
# #
# -fwrapv is needed for gcc to emit well-behaved code in the presence of # -fwrapv is needed for gcc to emit well-behaved code in the presence of
# integer wrap around. (Trac #952) # integer wrap around. (#952)
# #
AC_DEFUN([FP_GCC_EXTRA_FLAGS], AC_DEFUN([FP_GCC_EXTRA_FLAGS],
[AC_REQUIRE([FP_GCC_VERSION]) [AC_REQUIRE([FP_GCC_VERSION])
......
...@@ -124,7 +124,7 @@ mkJointDmds ss as = zipWithEqual "mkJointDmds" mkJointDmd ss as ...@@ -124,7 +124,7 @@ mkJointDmds ss as = zipWithEqual "mkJointDmds" mkJointDmd ss as
Note [Exceptions and strictness] Note [Exceptions and strictness]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We used to smart about catching exceptions, but we aren't anymore. We used to smart about catching exceptions, but we aren't anymore.
See Trac #14998 for the way it's resolved at the moment. See #14998 for the way it's resolved at the moment.
Here's a historic breakdown: Here's a historic breakdown:
...@@ -138,17 +138,17 @@ their argument, which is useful information for usage analysis. Still with a ...@@ -138,17 +138,17 @@ their argument, which is useful information for usage analysis. Still with a
In 7c0fff4 (July 15), Simon argued that giving `catch#` et al. a In 7c0fff4 (July 15), Simon argued that giving `catch#` et al. a
'strictApply1Dmd' leads to substantial performance gains. That was at the cost 'strictApply1Dmd' leads to substantial performance gains. That was at the cost
of correctness, as Trac #10712 proved. So, back to 'lazyApply1Dmd' in of correctness, as #10712 proved. So, back to 'lazyApply1Dmd' in
28638dfe79e (Dec 15). 28638dfe79e (Dec 15).
Motivated to reproduce the gains of 7c0fff4 without the breakage of Trac #10712, Motivated to reproduce the gains of 7c0fff4 without the breakage of #10712,
Ben opened Trac #11222. Simon made the demand analyser "understand catch" in Ben opened #11222. Simon made the demand analyser "understand catch" in
9915b656 (Jan 16) by adding a new 'catchArgDmd', which basically said to call 9915b656 (Jan 16) by adding a new 'catchArgDmd', which basically said to call
its argument strictly, but also swallow any thrown exceptions in its argument strictly, but also swallow any thrown exceptions in
'postProcessDmdResult'. This was realized by extending the 'Str' constructor of 'postProcessDmdResult'. This was realized by extending the 'Str' constructor of
'ArgStr' with a 'ExnStr' field, indicating that it catches the exception, and 'ArgStr' with a 'ExnStr' field, indicating that it catches the exception, and
adding a 'ThrowsExn' constructor to the 'Termination' lattice as an element adding a 'ThrowsExn' constructor to the 'Termination' lattice as an element
between 'Dunno' and 'Diverges'. Then along came Trac #11555 and finally #13330, between 'Dunno' and 'Diverges'. Then along came #11555 and finally #13330,
so we had to revert to 'lazyApply1Dmd' again in 701256df88c (Mar 17). so we had to revert to 'lazyApply1Dmd' again in 701256df88c (Mar 17).
This left the other variants like 'catchRetry#' having 'catchArgDmd', which is This left the other variants like 'catchRetry#' having 'catchArgDmd', which is
...@@ -159,10 +159,10 @@ there was none. We removed the last usages of 'catchArgDmd' in 00b8ecb7 ...@@ -159,10 +159,10 @@ there was none. We removed the last usages of 'catchArgDmd' in 00b8ecb7
removed in ef6b283 (Jan 19): We got rid of 'ThrowsExn' and 'ExnStr' again and removed in ef6b283 (Jan 19): We got rid of 'ThrowsExn' and 'ExnStr' again and
removed any code that was dealing with the peculiarities. removed any code that was dealing with the peculiarities.
Where did the speed-ups vanish to? In Trac #14998, item 3 established that Where did the speed-ups vanish to? In #14998, item 3 established that
turning 'catch#' strict in its first argument didn't bring back any of the turning 'catch#' strict in its first argument didn't bring back any of the
alleged performance benefits. Item 2 of that ticket finally found out that it alleged performance benefits. Item 2 of that ticket finally found out that it
was entirely due to 'catchException's new (since Trac #11555) definition, which was entirely due to 'catchException's new (since #11555) definition, which
was simply was simply
catchException !io handler = catch io handler catchException !io handler = catch io handler
...@@ -312,7 +312,7 @@ splitStrProdDmd n (SProd ds) = WARN( not (ds `lengthIs` n), ...@@ -312,7 +312,7 @@ splitStrProdDmd n (SProd ds) = WARN( not (ds `lengthIs` n),
Just ds Just ds
splitStrProdDmd _ (SCall {}) = Nothing splitStrProdDmd _ (SCall {}) = Nothing
-- This can happen when the programmer uses unsafeCoerce, -- This can happen when the programmer uses unsafeCoerce,
-- and we don't then want to crash the compiler (Trac #9208) -- and we don't then want to crash the compiler (#9208)
{- {-
************************************************************************ ************************************************************************
...@@ -482,7 +482,7 @@ addCaseBndrDmd (JD { sd = ms, ud = mu }) alt_dmds ...@@ -482,7 +482,7 @@ addCaseBndrDmd (JD { sd = ms, ud = mu }) alt_dmds
The demand on a binder in a case alternative comes The demand on a binder in a case alternative comes
(a) From the demand on the binder itself (a) From the demand on the binder itself
(b) From the demand on the case binder (b) From the demand on the case binder
Forgetting (b) led directly to Trac #10148. Forgetting (b) led directly to #10148.
Example. Source code: Example. Source code:
f x@(p,_) = if p then foo x else True f x@(p,_) = if p then foo x else True
...@@ -500,7 +500,7 @@ After strictness analysis: ...@@ -500,7 +500,7 @@ After strictness analysis:
True -> foo wild_X7 } True -> foo wild_X7 }
It's true that ds_dnz is *itself* absent, but the use of wild_X7 means It's true that ds_dnz is *itself* absent, but the use of wild_X7 means
that it is very much alive and demanded. See Trac #10148 for how the that it is very much alive and demanded. See #10148 for how the
consequences play out. consequences play out.
This is needed even for non-product types, in case the case-binder This is needed even for non-product types, in case the case-binder
...@@ -603,7 +603,7 @@ splitUseProdDmd n (UProd ds) = WARN( not (ds `lengthIs` n), ...@@ -603,7 +603,7 @@ splitUseProdDmd n (UProd ds) = WARN( not (ds `lengthIs` n),
Just ds Just ds
splitUseProdDmd _ (UCall _ _) = Nothing splitUseProdDmd _ (UCall _ _) = Nothing
-- This can happen when the programmer uses unsafeCoerce, -- This can happen when the programmer uses unsafeCoerce,
-- and we don't then want to crash the compiler (Trac #9208) -- and we don't then want to crash the compiler (#9208)
useCount :: Use u -> Count useCount :: Use u -> Count
useCount Abs = One useCount Abs = One
...@@ -627,7 +627,7 @@ isStrictDmd returns true only of demands that are ...@@ -627,7 +627,7 @@ isStrictDmd returns true only of demands that are
both strict both strict
and used and used
In particular, it is False for <HyperStr, Abs>, which can and does In particular, it is False for <HyperStr, Abs>, which can and does
arise in, say (Trac #7319) arise in, say (#7319)
f x = raise# <some exception> f x = raise# <some exception>
Then 'x' is not used, so f gets strictness <HyperStr,Abs> -> . Then 'x' is not used, so f gets strictness <HyperStr,Abs> -> .
Now the w/w generates Now the w/w generates
...@@ -637,7 +637,7 @@ At this point we really don't want to convert to ...@@ -637,7 +637,7 @@ At this point we really don't want to convert to
fx = case absentError "unused" of x -> raise <some exception> fx = case absentError "unused" of x -> raise <some exception>
Since the program is going to diverge, this swaps one error for another, Since the program is going to diverge, this swaps one error for another,
but it's really a bad idea to *ever* evaluate an absent argument. but it's really a bad idea to *ever* evaluate an absent argument.
In Trac #7319 we get In #7319 we get
T7319.exe: Oops! Entered absent arg w_s1Hd{v} [lid] [base:GHC.Base.String{tc 36u}] T7319.exe: Oops! Entered absent arg w_s1Hd{v} [lid] [base:GHC.Base.String{tc 36u}]
Note [Dealing with call demands] Note [Dealing with call demands]
...@@ -844,7 +844,7 @@ Consider this: ...@@ -844,7 +844,7 @@ Consider this:
where A,B are the constructors of a GADT. We'll get a U(U,U) demand where A,B are the constructors of a GADT. We'll get a U(U,U) demand
on x from the A branch, but that's a stupid demand for x itself, which on x from the A branch, but that's a stupid demand for x itself, which
has type 'a'. Indeed we get ASSERTs going off (notably in has type 'a'. Indeed we get ASSERTs going off (notably in
splitUseProdDmd, Trac #8569). splitUseProdDmd, #8569).
Bottom line: we really don't want to have a binder whose demand is more Bottom line: we really don't want to have a binder whose demand is more
deeply-nested than its type. There are various ways to tackle this. deeply-nested than its type. There are various ways to tackle this.
...@@ -1501,7 +1501,7 @@ There are several wrinkles: ...@@ -1501,7 +1501,7 @@ There are several wrinkles:
* In a previous incarnation of GHC we needed to be extra careful in the * In a previous incarnation of GHC we needed to be extra careful in the
case of an *unlifted type*, because unlifted values are evaluated case of an *unlifted type*, because unlifted values are evaluated
even if they are not used. Example (see Trac #9254): even if they are not used. Example (see #9254):
f :: (() -> (# Int#, () #)) -> () f :: (() -> (# Int#, () #)) -> ()
-- Strictness signature is -- Strictness signature is
-- <C(S(LS)), 1*C1(U(A,1*U()))> -- <C(S(LS)), 1*C1(U(A,1*U()))>
...@@ -1696,7 +1696,7 @@ That's fine: if we are doing strictness analysis we are also doing inlining, ...@@ -1696,7 +1696,7 @@ That's fine: if we are doing strictness analysis we are also doing inlining,
so we'll have inlined 'op' into a cast. So we can bale out in a conservative so we'll have inlined 'op' into a cast. So we can bale out in a conservative
way, returning nopDmdType. way, returning nopDmdType.
It is (just.. Trac #8329) possible to be running strictness analysis *without* It is (just.. #8329) possible to be running strictness analysis *without*
having inlined class ops from single-method classes. Suppose you are using having inlined class ops from single-method classes. Suppose you are using
ghc --make; and the first module has a local -O0 flag. So you may load a class ghc --make; and the first module has a local -O0 flag. So you may load a class
without interface pragmas, ie (currently) without an unfolding for the class without interface pragmas, ie (currently) without an unfolding for the class
......
...@@ -386,7 +386,7 @@ of reasons: ...@@ -386,7 +386,7 @@ of reasons:
* Look them up in the current substitution when we come across * Look them up in the current substitution when we come across
occurrences of them (in Subst.lookupIdSubst). Lacking this we occurrences of them (in Subst.lookupIdSubst). Lacking this we
can get an out-of-date unfolding, which can in turn make the can get an out-of-date unfolding, which can in turn make the
simplifier go into an infinite loop (Trac #9857) simplifier go into an infinite loop (#9857)
* Ensure that for dfuns that the specialiser does not float dict uses * Ensure that for dfuns that the specialiser does not float dict uses
above their defns, which would prevent good simplifications happening. above their defns, which would prevent good simplifications happening.
...@@ -560,7 +560,7 @@ un-saturated. Example: ...@@ -560,7 +560,7 @@ un-saturated. Example:
This has a compulsory unfolding because we can't lambda-bind those This has a compulsory unfolding because we can't lambda-bind those
arguments. But the compulsory unfolding may leave levity-polymorphic arguments. But the compulsory unfolding may leave levity-polymorphic
lambdas if it is not applied to enough arguments; e.g. (Trac #14561) lambdas if it is not applied to enough arguments; e.g. (#14561)
bad :: forall (a :: TYPE r). a -> a bad :: forall (a :: TYPE r). a -> a
bad = unsafeCoerce# bad = unsafeCoerce#
...@@ -569,7 +569,7 @@ And we want that magic to apply to levity-polymorphic compulsory-inline things. ...@@ -569,7 +569,7 @@ And we want that magic to apply to levity-polymorphic compulsory-inline things.
The easiest way to do this is for hasNoBinding to return True of all things The easiest way to do this is for hasNoBinding to return True of all things
that have compulsory unfolding. A very Ids with a compulsory unfolding also that have compulsory unfolding. A very Ids with a compulsory unfolding also
have a binding, but it does not harm to say they don't here, and its a very have a binding, but it does not harm to say they don't here, and its a very
simple way to fix Trac #14561. simple way to fix #14561.
Note [Primop wrappers] Note [Primop wrappers]
~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~
...@@ -942,7 +942,7 @@ where the '*' means 'LoopBreaker'. Then if we float we must get ...@@ -942,7 +942,7 @@ where the '*' means 'LoopBreaker'. Then if we float we must get
where g' is also marked as LoopBreaker. If not, terrible things where g' is also marked as LoopBreaker. If not, terrible things
can happen if we re-simplify the binding (and the Simplifier does can happen if we re-simplify the binding (and the Simplifier does
sometimes simplify a term twice); see Trac #4345. sometimes simplify a term twice); see #4345.
It's not so simple to retain It's not so simple to retain
* worker info * worker info
......
...@@ -159,9 +159,9 @@ okConIdOcc str = okIdOcc str || ...@@ -159,9 +159,9 @@ okConIdOcc str = okIdOcc str ||
is_tuple_name1 True str || is_tuple_name1 True str ||
-- Is it a boxed tuple... -- Is it a boxed tuple...
is_tuple_name1 False str || is_tuple_name1 False str ||
-- ...or an unboxed tuple (Trac #12407)... -- ...or an unboxed tuple (#12407)...
is_sum_name1 str is_sum_name1 str
-- ...or an unboxed sum (Trac #12514)? -- ...or an unboxed sum (#12514)?
where where
-- check for tuple name, starting at the beginning -- check for tuple name, starting at the beginning
is_tuple_name1 True ('(' : rest) = is_tuple_name2 True rest is_tuple_name1 True ('(' : rest) = is_tuple_name2 True rest
......
...@@ -746,7 +746,7 @@ constructor has no wrapper, but whether a constructor has a wrapper depends, for ...@@ -746,7 +746,7 @@ constructor has no wrapper, but whether a constructor has a wrapper depends, for
instance, on the order of type argument of that constructors. Therefore changing instance, on the order of type argument of that constructors. Therefore changing
the order of type argument could make previously working RULEs fail. the order of type argument could make previously working RULEs fail.
See also https://ghc.haskell.org/trac/ghc/ticket/15840 . See also https://gitlab.haskell.org/ghc/ghc/issues/15840 .
Note [Bangs on imported data constructors] Note [Bangs on imported data constructors]
...@@ -778,7 +778,7 @@ We certainly do not want to make a wrapper ...@@ -778,7 +778,7 @@ We certainly do not want to make a wrapper
For a start, it's still to generate a no-op. But worse, since wrappers For a start, it's still to generate a no-op. But worse, since wrappers
are currently injected at TidyCore, we don't even optimise it away! are currently injected at TidyCore, we don't even optimise it away!
So the stupid case expression stays there. This actually happened for So the stupid case expression stays there. This actually happened for
the Integer data type (see Trac #1600 comment:66)! the Integer data type (see #1600 comment:66)!
Note [Data con wrappers and GADT syntax] Note [Data con wrappers and GADT syntax]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...@@ -821,7 +821,7 @@ strictness/unpackedness to use for the fields of a data type constructor. But ...@@ -821,7 +821,7 @@ strictness/unpackedness to use for the fields of a data type constructor. But
there is an exception to this rule: newtype constructors. You might not think there is an exception to this rule: newtype constructors. You might not think
that newtypes would pose a challenge, since newtypes are seemingly forbidden that newtypes would pose a challenge, since newtypes are seemingly forbidden
from having strictness annotations in the first place. But consider this from having strictness annotations in the first place. But consider this
(from Trac #16141): (from #16141):
{-# LANGUAGE StrictData #-} {-# LANGUAGE StrictData #-}
{-# OPTIONS_GHC -O #-} {-# OPTIONS_GHC -O #-}
...@@ -1045,7 +1045,7 @@ And it'd be fine to unpack a product type with existential components ...@@ -1045,7 +1045,7 @@ And it'd be fine to unpack a product type with existential components
too, but that would require a bit more plumbing, so currently we don't. too, but that would require a bit more plumbing, so currently we don't.
So for now we require: null (dataConExTyCoVars data_con) So for now we require: null (dataConExTyCoVars data_con)
See Trac #14978 See #14978
Note [Unpack one-wide fields] Note [Unpack one-wide fields]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...@@ -1175,7 +1175,7 @@ mkPrimOpId prim_op ...@@ -1175,7 +1175,7 @@ mkPrimOpId prim_op
-- We give PrimOps a NOINLINE pragma so that we don't -- We give PrimOps a NOINLINE pragma so that we don't
-- get silly warnings from Desugar.dsRule (the inline_shadows_rule -- get silly warnings from Desugar.dsRule (the inline_shadows_rule
-- test) about a RULE conflicting with a possible inlining -- test) about a RULE conflicting with a possible inlining
-- cf Trac #7287 -- cf #7287
-- For each ccall we manufacture a separate CCallOpId, giving it -- For each ccall we manufacture a separate CCallOpId, giving it
-- a fresh unique, a type that is correct for this particular ccall, -- a fresh unique, a type that is correct for this particular ccall,
...@@ -1209,7 +1209,7 @@ mkFCallId dflags uniq fcall ty ...@@ -1209,7 +1209,7 @@ mkFCallId dflags uniq fcall ty
strict_sig = mkClosedStrictSig (replicate arity topDmd) topRes strict_sig = mkClosedStrictSig (replicate arity topDmd) topRes
-- the call does not claim to be strict in its arguments, since they -- the call does not claim to be strict in its arguments, since they
-- may be lifted (foreign import prim) and the called code doesn't -- may be lifted (foreign import prim) and the called code doesn't
-- necessarily force them. See Trac #11076. -- necessarily force them. See #11076.
{- {-
************************************************************************ ************************************************************************
* * * *
...@@ -1499,7 +1499,7 @@ are truly used call-by-need, with no code motion. Key examples: ...@@ -1499,7 +1499,7 @@ are truly used call-by-need, with no code motion. Key examples:
Again, it's clear that 'a' will be evaluated strictly (and indeed Again, it's clear that 'a' will be evaluated strictly (and indeed
applied to a state token) but we want to make sure that any exceptions applied to a state token) but we want to make sure that any exceptions
arising from the evaluation of 'a' are caught by the catch (see arising from the evaluation of 'a' are caught by the catch (see
Trac #11555). #11555).
Implementing 'lazy' is a bit tricky: Implementing 'lazy' is a bit tricky:
...@@ -1513,7 +1513,7 @@ Implementing 'lazy' is a bit tricky: ...@@ -1513,7 +1513,7 @@ Implementing 'lazy' is a bit tricky:
are exposed in the interface file. Otherwise, the unfolding for are exposed in the interface file. Otherwise, the unfolding for
(say) pseq in the interface file will not mention 'lazy', so if we (say) pseq in the interface file will not mention 'lazy', so if we
inline 'pseq' we'll totally miss the very thing that 'lazy' was inline 'pseq' we'll totally miss the very thing that 'lazy' was
there for in the first place. See Trac #3259 for a real world there for in the first place. See #3259 for a real world
example. example.
* Suppose CorePrep sees (catch# (lazy e) b). At all costs we must * Suppose CorePrep sees (catch# (lazy e) b). At all costs we must
...@@ -1550,7 +1550,7 @@ if library authors could explicitly tell the compiler that a certain lambda is ...@@ -1550,7 +1550,7 @@ if library authors could explicitly tell the compiler that a certain lambda is
called at most once. The oneShot function allows that. called at most once. The oneShot function allows that.
'oneShot' is levity-polymorphic, i.e. the type variables can refer to unlifted 'oneShot' is levity-polymorphic, i.e. the type variables can refer to unlifted
types as well (Trac #10744); e.g. types as well (#10744); e.g.
oneShot (\x:Int# -> x +# 1#) oneShot (\x:Int# -> x +# 1#)
Like most magic functions it has a compulsory unfolding, so there is no need Like most magic functions it has a compulsory unfolding, so there is no need
......
...@@ -199,7 +199,7 @@ import {-# SOURCE #-} Packages (componentIdString, improveUnitId, PackageConfigM ...@@ -199,7 +199,7 @@ import {-# SOURCE #-} Packages (componentIdString, improveUnitId, PackageConfigM
-- only ever ComponentIds, and some ComponentIds happen to have -- only ever ComponentIds, and some ComponentIds happen to have
-- more information (UnitIds). -- more information (UnitIds).
-- - Same as Language.Haskell.TH.Syntax:PkgName, see -- - Same as Language.Haskell.TH.Syntax:PkgName, see
-- https://ghc.haskell.org/trac/ghc/ticket/10279 -- https://gitlab.haskell.org/ghc/ghc/issues/10279
-- - The same as PackageKey in GHC 7.10 (we renamed it because -- - The same as PackageKey in GHC 7.10 (we renamed it because
-- they don't necessarily identify packages anymore.) -- they don't necessarily identify packages anymore.)
-- - Same as -this-package-key/-package-name flags -- - Same as -this-package-key/-package-name flags
...@@ -217,7 +217,7 @@ import {-# SOURCE #-} Packages (componentIdString, improveUnitId, PackageConfigM ...@@ -217,7 +217,7 @@ import {-# SOURCE #-} Packages (componentIdString, improveUnitId, PackageConfigM
-- PackageName: The "name" field in a Cabal file, something like "lens". -- PackageName: The "name" field in a Cabal file, something like "lens".
-- - Same as Distribution.Package.PackageName -- - Same as Distribution.Package.PackageName
-- - DIFFERENT FROM Language.Haskell.TH.Syntax:PkgName, see -- - DIFFERENT FROM Language.Haskell.TH.Syntax:PkgName, see
-- https://ghc.haskell.org/trac/ghc/ticket/10279 -- https://gitlab.haskell.org/ghc/ghc/issues/10279
-- - DIFFERENT FROM -package-name flag -- - DIFFERENT FROM -package-name flag
-- - DIFFERENT FROM the 'name' field in an installed package -- - DIFFERENT FROM the 'name' field in an installed package
-- information. This field could more accurately be described -- information. This field could more accurately be described
......
...@@ -68,7 +68,7 @@ are two reasons why we might look up an Orig RdrName for built-in syntax, ...@@ -68,7 +68,7 @@ are two reasons why we might look up an Orig RdrName for built-in syntax,
* Template Haskell turns a BuiltInSyntax Name into a TH.NameG * Template Haskell turns a BuiltInSyntax Name into a TH.NameG
(DsMeta.globalVar), and parses a NameG into an Orig RdrName (DsMeta.globalVar), and parses a NameG into an Orig RdrName
(Convert.thRdrName). So, e.g. $(do { reify '(,); ... }) will (Convert.thRdrName). So, e.g. $(do { reify '(,); ... }) will
go this route (Trac #8954). go this route (#8954).
-} -}
......
...@@ -790,7 +790,7 @@ type TidyOccEnv = UniqFM Int ...@@ -790,7 +790,7 @@ type TidyOccEnv = UniqFM Int
- We use trailing digits to subtly indicate a unification variable - We use trailing digits to subtly indicate a unification variable
in typechecker error message; see TypeRep.tidyTyVarBndr in typechecker error message; see TypeRep.tidyTyVarBndr
We have to take care though! Consider a machine-generated module (Trac #10370) We have to take care though! Consider a machine-generated module (#10370)
module Foo where module Foo where
a1 = e1 a1 = e1
a2 = e2 a2 = e2
......
...@@ -118,7 +118,7 @@ In a pattern synonym signature we write ...@@ -118,7 +118,7 @@ In a pattern synonym signature we write