Nearly all uses of `uniqCompareFS` are dubious and lack a non-determinism justification
$ rg uniqCompareFS
utils/haddock/haddock-api/src/Haddock/Interface/Specialize.hs
185: compare (NameRep fs1) (NameRep fs2) = uniqCompareFS fs1 fs2
compiler/GHC/Iface/Ext/Types.hs
308: = mconcat [uniqCompareFS c0 c1, uniqCompareFS t0 t1]
compiler/GHC/Cmm/CLabel.hs
326: uniqCompareFS c1 c2 `thenCmp`
331: uniqCompareFS a1 a2 `thenCmp`
338: uniqCompareFS b1 b2
compiler/GHC/Core/TyCo/Rep.hs
197: compare (StrTyLit x) (StrTyLit y) = uniqCompareFS x y
compiler/GHC/Core/Opt/Monad.hs
550:cmpEqTick (RuleFired a) (RuleFired b) = a `uniqCompareFS` b
compiler/Language/Haskell/Syntax/Lit.hs
166: compare (HsIsString _ s1) (HsIsString _ s2) = s1 `uniqCompareFS` s2
compiler/GHC/Tc/TyCl.hs
4171: cmp_fld (f1,_) (f2,_) = flLabel f1 `uniqCompareFS` flLabel f2
compiler/GHC/Data/FastString.hs
26:-- * O(1) but non-deterministic with Unique comparison (`uniqCompareFS`)
91: uniqCompareFS,
218:-- * by unique: non-deterministic, O(1). Cf uniqCompareFS and NonDetFastString.
245:-- If you don't care about the lexical ordering, use `uniqCompareFS` instead.
256:uniqCompareFS :: FastString -> FastString -> Ordering
257:uniqCompareFS fs1 fs2 = compare (uniq fs1) (uniq fs2)
262:-- `uniqCompareFS` (i.e. which compares FastStrings on their Uniques). Hence it
269: compare (NonDetFastString fs1) (NonDetFastString fs2) = uniqCompareFS fs1 fs2
compiler/GHC/Unit/Types.hs
293: u1 `compare` u2 = instUnitFS u1 `uniqCompareFS` instUnitFS u2
Except for compiler/GHC/Data/FastString.hs, all of these files contain mentions of uniqCompareFS
for which I couldn't immediately see how they would not affect the compiler output.
All of these should use lexicallyCompareFS
. Heck, we should add back the Ord FastString
instance and make it lexicallyCompareFS
and use NonDeterministicFastString
if we need the faster Unique-based instance.