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.
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
`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.
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
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)
as well as a guide on
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
[how to use Phabricator/arcanist](https://ghc.haskell.org/trac/ghc/wiki/Phabricator).
......
......@@ -22,7 +22,7 @@ MAKEFLAGS += --no-builtin-rules
# -----------------------------------------------------------------------------
# Sanitize environment
# See Trac #11530
# See #11530
export GREP_OPTIONS :=
ifneq "$(filter maintainer-clean distclean clean clean_% help,$(MAKECMDGOALS))" ""
......
......@@ -8,7 +8,7 @@ environment for the Haskell functional programming language.
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
......
......@@ -1483,7 +1483,7 @@ AC_SUBST([GhcPkgCmd])
# to compile .hc code.
#
# -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_REQUIRE([FP_GCC_VERSION])
......
......@@ -124,7 +124,7 @@ mkJointDmds ss as = zipWithEqual "mkJointDmds" mkJointDmd ss as
Note [Exceptions and strictness]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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:
......@@ -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
'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).
Motivated to reproduce the gains of 7c0fff4 without the breakage of Trac #10712,
Ben opened Trac #11222. Simon made the demand analyser "understand catch" in
Motivated to reproduce the gains of 7c0fff4 without the breakage of #10712,
Ben opened #11222. Simon made the demand analyser "understand catch" in
9915b656 (Jan 16) by adding a new 'catchArgDmd', which basically said to call
its argument strictly, but also swallow any thrown exceptions in
'postProcessDmdResult'. This was realized by extending the 'Str' constructor of
'ArgStr' with a 'ExnStr' field, indicating that it catches the exception, and
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).
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
removed in ef6b283 (Jan 19): We got rid of 'ThrowsExn' and 'ExnStr' again and
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
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
catchException !io handler = catch io handler
......@@ -312,7 +312,7 @@ splitStrProdDmd n (SProd ds) = WARN( not (ds `lengthIs` n),
Just ds
splitStrProdDmd _ (SCall {}) = Nothing
-- 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
The demand on a binder in a case alternative comes
(a) From the demand on the binder itself
(b) From the demand on the case binder
Forgetting (b) led directly to Trac #10148.
Forgetting (b) led directly to #10148.
Example. Source code:
f x@(p,_) = if p then foo x else True
......@@ -500,7 +500,7 @@ After strictness analysis:
True -> foo wild_X7 }
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.
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),
Just ds
splitUseProdDmd _ (UCall _ _) = Nothing
-- 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 Abs = One
......@@ -627,7 +627,7 @@ isStrictDmd returns true only of demands that are
both strict
and used
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>
Then 'x' is not used, so f gets strictness <HyperStr,Abs> -> .
Now the w/w generates
......@@ -637,7 +637,7 @@ At this point we really don't want to convert to
fx = case absentError "unused" of x -> raise <some exception>
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.
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}]
Note [Dealing with call demands]
......@@ -844,7 +844,7 @@ Consider this:
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
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
deeply-nested than its type. There are various ways to tackle this.
......@@ -1501,7 +1501,7 @@ There are several wrinkles:
* In a previous incarnation of GHC we needed to be extra careful in the
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#, () #)) -> ()
-- Strictness signature is
-- <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,
so we'll have inlined 'op' into a cast. So we can bale out in a conservative
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
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
......
......@@ -386,7 +386,7 @@ of reasons:
* Look them up in the current substitution when we come across
occurrences of them (in Subst.lookupIdSubst). Lacking this we
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
above their defns, which would prevent good simplifications happening.
......@@ -560,7 +560,7 @@ un-saturated. Example:
This has a compulsory unfolding because we can't lambda-bind those
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 = unsafeCoerce#
......@@ -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
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
simple way to fix Trac #14561.
simple way to fix #14561.
Note [Primop wrappers]
~~~~~~~~~~~~~~~~~~~~~~
......@@ -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
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
* worker info
......
......@@ -159,9 +159,9 @@ okConIdOcc str = okIdOcc str ||
is_tuple_name1 True str ||
-- Is it a boxed tuple...
is_tuple_name1 False str ||
-- ...or an unboxed tuple (Trac #12407)...
-- ...or an unboxed tuple (#12407)...
is_sum_name1 str
-- ...or an unboxed sum (Trac #12514)?
-- ...or an unboxed sum (#12514)?
where
-- check for tuple name, starting at the beginning
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
instance, on the order of type argument of that constructors. Therefore changing
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]
......@@ -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
are currently injected at TidyCore, we don't even optimise it away!
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]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
......@@ -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
that newtypes would pose a challenge, since newtypes are seemingly forbidden
from having strictness annotations in the first place. But consider this
(from Trac #16141):
(from #16141):
{-# LANGUAGE StrictData #-}
{-# OPTIONS_GHC -O #-}
......@@ -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.
So for now we require: null (dataConExTyCoVars data_con)
See Trac #14978
See #14978
Note [Unpack one-wide fields]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
......@@ -1175,7 +1175,7 @@ mkPrimOpId prim_op
-- We give PrimOps a NOINLINE pragma so that we don't
-- get silly warnings from Desugar.dsRule (the inline_shadows_rule
-- test) about a RULE conflicting with a possible inlining
-- cf Trac #7287
-- cf #7287
-- For each ccall we manufacture a separate CCallOpId, giving it
-- a fresh unique, a type that is correct for this particular ccall,
......@@ -1209,7 +1209,7 @@ mkFCallId dflags uniq fcall ty
strict_sig = mkClosedStrictSig (replicate arity topDmd) topRes
-- 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
-- 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:
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
arising from the evaluation of 'a' are caught by the catch (see
Trac #11555).
#11555).
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
(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
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.
* 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
called at most once. The oneShot function allows that.
'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#)
Like most magic functions it has a compulsory unfolding, so there is no need
......
......@@ -199,7 +199,7 @@ import {-# SOURCE #-} Packages (componentIdString, improveUnitId, PackageConfigM
-- only ever ComponentIds, and some ComponentIds happen to have
-- more information (UnitIds).
-- - 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
-- they don't necessarily identify packages anymore.)
-- - Same as -this-package-key/-package-name flags
......@@ -217,7 +217,7 @@ import {-# SOURCE #-} Packages (componentIdString, improveUnitId, PackageConfigM
-- PackageName: The "name" field in a Cabal file, something like "lens".
-- - Same as Distribution.Package.PackageName
-- - 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 the 'name' field in an installed package
-- 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,
* Template Haskell turns a BuiltInSyntax Name into a TH.NameG
(DsMeta.globalVar), and parses a NameG into an Orig RdrName
(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
- We use trailing digits to subtly indicate a unification variable
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
a1 = e1
a2 = e2
......
......@@ -118,7 +118,7 @@ In a pattern synonym signature we write
Note that the "required" context comes first, then the "provided"
context. Moreover, the "required" context must not mention
existentially-bound type variables; that is, ones not mentioned in
res_ty. See lots of discussion in Trac #10928.
res_ty. See lots of discussion in #10928.
If there is no "provided" context, you can omit it; but you
can't omit the "required" part (unless you omit both).
......
......@@ -509,7 +509,7 @@ gre_lcl is True, or gre_imp is non-empty.
It is just possible to have *both* if there is a module loop: a Name
is defined locally in A, and also brought into scope by importing a
module that SOURCE-imported A. Exapmle (Trac #7672):
module that SOURCE-imported A. Exapmle (#7672):
A.hs-boot module A where
data T
......@@ -1256,7 +1256,7 @@ Rationale for (a). Consider
The unqualified 'x' can only come from import #2. The qualified 'M.x'
could come from either, but bestImport picks import #2, because it is
more likely to be useful in other imports, as indeed it is in this
case (see Trac #5211 for a concrete example).
case (see #5211 for a concrete example).
But the rules are not perfect; consider
import qualified M -- Import #1
......
......@@ -133,7 +133,7 @@ elemLRegSet l = IntSet.member (getKey (getUnique l))
--
-- a nice loop, but we didn't eliminate the silly assignment at the end.
-- See Note [dependent assignments], which would probably fix this.
-- This is #8336 on Trac.
-- This is #8336.
--
-- -----------
-- (2) From stg_atomically_frame in PrimOps.cmm
......
......@@ -448,7 +448,7 @@ regsOverlap _ reg reg' = reg == reg'
--
-- We must check for overlapping registers and not just equal
-- registers here, otherwise CmmSink may incorrectly reorder
-- assignments that conflict due to overlap. See #10521 and Note
-- [Overlapping global registers].
regUsedIn :: DynFlags -> CmmReg -> CmmExpr -> Bool
regUsedIn dflags = regUsedIn_ where
......
......@@ -179,7 +179,7 @@ pprAlignment words =
--
-- It's a reasonable assumption also known as natural alignment.
-- Although some architectures have different alignment rules.
-- One of known exceptions is m68k (Trac #11395, comment:16) where:
-- One of known exceptions is m68k (#11395, comment:16) where:
-- __alignof__(StgWord) == 2, sizeof(StgWord) == 4
--
-- Thus we explicitly increase alignment by using
......
......@@ -732,7 +732,7 @@ blackHoleOnEntry cl_info
{- Note [Black-holing non-updatable thunks]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We must not black-hole non-updatable (single-entry) thunks otherwise
we run into issues like Trac #10414. Specifically:
we run into issues like #10414. Specifically:
* There is no reason to black-hole a non-updatable thunk: it should
not be competed for by multiple threads
......@@ -745,7 +745,7 @@ we run into issues like Trac #10414. Specifically:
- is not updated (of course)
- hence, if it is black-holed and another thread tries to evaluate
it, that thread will block forever
This actually happened in Trac #10414. So we do not black-hole
This actually happened in #10414. So we do not black-hole
non-updatable thunks.
* How could two threads evaluate the same non-updatable (single-entry)
......@@ -755,7 +755,7 @@ we run into issues like Trac #10414. Specifically:
thunk, because lazy black-holing only affects thunks with an
update frame on the stack.
Here is and example due to Reid Barton (Trac #10414):
Here is and example due to Reid Barton (#10414):
x = \u [] concat [[1], []]
with the following definitions,
......
......@@ -375,7 +375,7 @@ Suppose we have this STG code:
f = \[s : State# RealWorld] ->
case s of _ -> blah
This is very odd. Why are we scrutinising a state token? But it
can arise with bizarre NOINLINE pragmas (Trac #9964)
can arise with bizarre NOINLINE pragmas (#9964)
crash :: IO ()
crash = IO (\s -> let {-# NOINLINE s' #-}
s' = s
......@@ -532,7 +532,7 @@ See Note [case on bool]
It's odd, and it's flagrantly inconsistent with the rules described
Note [Compiling case expressions]. However, after eliminating the
tagToEnum# (Trac #13397) we will have:
tagToEnum# (#13397) we will have:
case (a>b) of ...
Rather than make it behave quite differently, I am testing for a
comparison operator here in in the general case as well.
......
......@@ -519,7 +519,7 @@ heapCheck checkStack checkYield do_gc code
[" Trying to allocate more than "++show mBLOCK_SIZE++" bytes.",
"",
"This is currently not possible due to a limitation of GHC's code generator.",
"See http://ghc.haskell.org/trac/ghc/ticket/4505 for details.",
"See https://gitlab.haskell.org/ghc/ghc/issues/4505 for details.",
"Suggestion: read data from a file instead of having large static data",
"structures in code."]
| hpHw > 0 = Just (mkIntExpr dflags (hpHw * (wORD_SIZE dflags)))
......
......@@ -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
......
......@@ -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