[Git][ghc/ghc][wip/T22141] 37 commits: Fix restarts in .ghcid

Ryan Scott (@RyanGlScott) gitlab at gitlab.haskell.org
Fri Oct 27 20:31:40 UTC 2023



Ryan Scott pushed to branch wip/T22141 at Glasgow Haskell Compiler / GHC


Commits:
a0ac8785 by Sebastian Graf at 2023-10-14T19:17:12-04:00
Fix restarts in .ghcid

Using the whole of `hadrian/` restarted in a loop for me.

- - - - -
fea9ecdb by Sebastian Graf at 2023-10-14T19:17:12-04:00
CorePrep: Refactor FloatingBind (#23442)

A drastically improved architecture for local floating in CorePrep
that decouples the decision of whether a float is going to be let- or case-bound
from how far it can float (out of strict contexts, out of lazy contexts, to
top-level).

There are a couple of new Notes describing the effort:

  * `Note [Floating in CorePrep]` for the overview
  * `Note [BindInfo and FloatInfo]` for the new classification of floats
  * `Note [Floats and FloatDecision]` for how FloatInfo is used to inform
    floating decisions

This is necessary ground work for proper treatment of Strict fields and
unlifted values at top-level.

Fixes #23442.

NoFib results (omitted = 0.0%):
```
--------------------------------------------------------------------------------
        Program         Allocs    Instrs
--------------------------------------------------------------------------------
         pretty           0.0%     -1.6%
            scc           0.0%     -1.7%
--------------------------------------------------------------------------------
            Min           0.0%     -1.7%
            Max           0.0%     -0.0%
 Geometric Mean          -0.0%     -0.0%
```

- - - - -
32523713 by Matthew Pickering at 2023-10-14T19:17:49-04:00
hadrian: Move ghcBinDeps into ghcLibDeps

This completes a5227080b57cb51ac34d4c9de1accdf6360b818b, the
`ghc-usage.txt` and `ghci-usage.txt` file are also used by the `ghc`
library so need to make sure they are present in the libdir even if we
are not going to build `ghc-bin`.

This also fixes things for cross compilers because the stage2
cross-compiler requires the ghc-usage.txt file, but we are using
the stage2 lib folder but not building stage3:exe:ghc-bin so
ghc-usage.txt was not being generated.

- - - - -
ec3c4488 by sheaf at 2023-10-14T19:18:29-04:00
Combine GREs when combining in mkImportOccEnv

In `GHC.Rename.Names.mkImportOccEnv`, we sometimes discard one import
item in favour of another, as explained in Note [Dealing with imports]
in `GHC.Rename.Names`. However, this can cause us to lose track of
important parent information.

Consider for example #24084:

  module M1 where { class C a where { type T a } }
  module M2 ( module M1 ) where { import M1 }
  module M3 where { import M2 ( C, T ); instance C () where T () = () }

When processing the import list of `M3`, we start off (for reasons that
are not relevant right now) with two `Avail`s attached to `T`, namely
`C(C, T)` and `T(T)`. We combine them in the `combine` function of
`mkImportOccEnv`; as described in Note [Dealing with imports] we discard
`C(C, T)` in favour of `T(T)`. However, in doing so, we **must not**
discard the information want that `C` is the parent of `T`. Indeed,
losing track of this information can cause errors when importing,
as we could get an error of the form

  ‘T’ is not a (visible) associated type of class ‘C’

We fix this by combining the two GREs for `T` using `plusGRE`.

Fixes #24084

- - - - -
257c2807 by Ilias Tsitsimpis at 2023-10-14T19:19:07-04:00
hadrian: Pass -DNOSMP to C compiler when needed

Hadrian passes the -DNOSMP flag to GHC when the target doesn't support
SMP, but doesn't pass it to CC as well, leading to the following
compilation error on mips64el:

| Run Cc (FindCDependencies CDep) Stage1: rts/sm/NonMovingScav.c => _build/stage1/rts/build/c/sm/NonMovingScav.o.d
Command line: /usr/bin/mips64el-linux-gnuabi64-gcc -E -MM -MG -MF _build/stage1/rts/build/c/hooks/FlagDefaults.thr_debug_p_o.d -MT _build/stage1/rts/build/c/hooks/FlagDefaults.o -Irts/include -I_build/stage1/rts/build -I_build/stage1/rts/build/include -Irts/include -x c rts/hooks/FlagDefaults.c -Wall -Wextra -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Winline -Wpointer-arith -Wmissing-noreturn -Wnested-externs -Wredundant-decls -Wundef -fno-strict-aliasing -DTHREADED_RTS -DDEBUG -fomit-frame-pointer -O2 -g -Irts -I_build/stage1/rts/build -DDEBUG -fno-omit-frame-pointer -g3 -O0
===> Command failed with error code: 1
In file included from rts/include/Stg.h:348,
                 from rts/include/Rts.h:38,
                 from rts/hooks/FlagDefaults.c:8:
rts/include/stg/SMP.h:416:2: error: #error memory barriers unimplemented on this architecture
  416 | #error memory barriers unimplemented on this architecture
      |  ^~~~~
rts/include/stg/SMP.h:440:2: error: #error memory barriers unimplemented on this architecture
  440 | #error memory barriers unimplemented on this architecture
      |  ^~~~~
rts/include/stg/SMP.h:464:2: error: #error memory barriers unimplemented on this architecture
  464 | #error memory barriers unimplemented on this architecture
      |  ^~~~~

The old make system correctly passed this flag to both GHC and CC [1].

Fix this error by passing -DNOSMP to CC as well.

[1] https://gitlab.haskell.org/ghc/ghc/-/blob/00920f176b0235d5bb52a8e054d89a664f8938fe/rts/ghc.mk#L407

Closes #24082

- - - - -
13d3c613 by John Ericson at 2023-10-14T19:19:42-04:00
Users Guide: Drop dead code for Haddock refs to `parallel`

I noticed while working on !11451 that `@LIBRARY_parallel_UNIT_ID@` was
not substituted. It is dead code -- there is no `parallel-ref` usages
and it doesn't look like there ever was (going back to
3e5d0f188d6c8633e55e9ba6c8941c07e459fa4b), so let's delete it.

- - - - -
fe067577 by Sylvain Henry at 2023-10-18T19:40:25-04:00
Avoid out-of-bound array access in bigNatIsPowerOf2 (fix #24066)

bigNatIndex# in the `where` clause wasn't guarded by "bigNatIsZero a".

- - - - -
cc1625b1 by Sylvain Henry at 2023-10-18T19:40:25-04:00
Bignum: fix right shift of negative BigNat with native backend

- - - - -
cbe4400d by Sylvain Henry at 2023-10-18T19:40:25-04:00
Rts: expose rtsOutOfBoundsAccess symbol

- - - - -
72c7380c by Sylvain Henry at 2023-10-18T19:40:25-04:00
Hadrian: enable `-fcheck-prim-bounds` in validate flavour

This allows T24066 to fail when the bug is present.

Otherwise the out-of-bound access isn't detected as it happens in
ghc-bignum which wasn't compiled with the bounds check.

- - - - -
f9436990 by John Ericson at 2023-10-18T19:41:01-04:00
Make Hadrian solely responsible for substituting `docs/users_guide/ghc_config.py.in`

Fixes #24091
Progress on #23966

Issue #24091 reports that `@ProjectVersion@` is no longer being
substituted in the GHC user's guide. I assume this is a recent issue,
but I am not sure how it's worked since
c1a3ecde720b3bddc2c8616daaa06ee324e602ab; it looks like both Hadrian and
configure are trying to substitute the same `.in` file!

Now only Hadrian does. That is better anyways; already something that
issue #23966 requested.

It seems like we were missing some dependencies in Hadrian. (I really,
really hate that this is possible!) Hopefully it is fixed now.

- - - - -
b12df0bb by John Ericson at 2023-10-18T19:41:37-04:00
`ghcversion.h`: No need to cope with undefined `ProjectPatchLevel*`

Since 4e6c80197f1cc46dfdef0300de46847c7cfbdcb0, these are guaranteed to
be defined. (Guaranteed including a test in the testsuite.)

- - - - -
0295375a by John Ericson at 2023-10-18T19:41:37-04:00
Generate `ghcversion.h` from a `.in` file

Now that there are no conditional sections (see the previous commit), we
can just a do simple substitution rather than pasting it together line
by line.

Progress on #23966

- - - - -
740a1b85 by Krzysztof Gogolewski at 2023-10-19T11:37:20-04:00
Add a regression test for #24064

- - - - -
921fbf2f by Hécate Moonlight at 2023-10-19T11:37:59-04:00
CLC Proposal #182: Export List from Data.List

Proposal link: https://github.com/haskell/core-libraries-committee/issues/182

- - - - -
4f02d3c1 by Sylvain Henry at 2023-10-20T04:01:32-04:00
rts: fix small argument passing on big-endian arch (fix #23387)

- - - - -
b86243b4 by Sylvain Henry at 2023-10-20T04:02:13-04:00
Interpreter: fix literal alignment on big-endian architectures (fix #19261)

Literals weren't correctly aligned on big-endian, despite what the
comment said.

- - - - -
a4b2ec47 by Sylvain Henry at 2023-10-20T04:02:54-04:00
Testsuite: recomp011 and recomp015 are fixed on powerpc

These tests have been fixed but not tested and re-enabled on big-endian
powerpc (see comments in #11260 and #11323)

- - - - -
fded7dd4 by Sebastian Graf at 2023-10-20T04:03:30-04:00
CorePrep: Allow floating dictionary applications in -O0 into a Rec (#24102)
- - - - -
02efc181 by John Ericson at 2023-10-22T02:48:55-04:00
Move function checks to RTS configure

Some of these functions are used in `base` too, but we can copy the
checks over to its configure if that's an issue.

- - - - -
5f4bccab by John Ericson at 2023-10-22T02:48:55-04:00
Move over a number of C-style checks to RTS configure

- - - - -
5cf04f58 by John Ericson at 2023-10-22T02:48:55-04:00
Move/Copy more `AC_DEFINE` to RTS config

Only exception is the LLVM version macros, which are used for GHC
itself.

- - - - -
b8ce5dfe by John Ericson at 2023-10-22T02:48:55-04:00
Define `TABLES_NEXT_TO_CODE` in the RTS configure

We create a new cabal flag to facilitate this.

- - - - -
4a40271e by John Ericson at 2023-10-22T02:48:55-04:00
Configure scripts: `checkOS`: Make a bit more robust

`mingw64` and `mingw32` are now both accepted for `OSMinGW32`. This
allows us to cope with configs/triples that we haven't normalized extra
being what GNU `config.sub` does.

- - - - -
16bec0a0 by John Ericson at 2023-10-22T02:48:55-04:00
Generate `ghcplatform.h` from RTS configure

We create a new cabal flag to facilitate this.

- - - - -
7dfcab2f by John Ericson at 2023-10-22T02:48:55-04:00
Get rid of all mention of `mk/config.h`

The RTS configure script is now solely responsible for managing its
headers; the top level configure script does not help.

- - - - -
c1e3719c by Cheng Shao at 2023-10-22T02:49:33-04:00
rts: drop stale mentions of MIN_UPD_SIZE

We used to have MIN_UPD_SIZE macro that describes the minimum reserved
size for thunks, so that the thunk can be overwritten in place as
indirections or blackholes. However, this macro has not been actually
defined or used anywhere since a long time ago; StgThunkHeader already
reserves a padding word for this purpose. Hence this patch which drops
stale mentions of MIN_UPD_SIZE.

- - - - -
d24b0d85 by Andrew Lelechenko at 2023-10-22T02:50:11-04:00
base changelog: move non-backported entries from 4.19 section to 4.20

Neither !10933 (check https://hackage.haskell.org/package/base-4.19.0.0/docs/src/Text.Read.Lex.html#numberToRangedRational)
nor !10189 (check https://hackage.haskell.org/package/base-4.19.0.0/docs/src/Data.List.NonEmpty.html#unzip)
were backported to `base-4.19.0.0`. Moving them to `base-4.20.0.0` section.

Also minor stylistic changes to other entries, bringing them to a uniform form.

- - - - -
de78b32a by Alan Zimmerman at 2023-10-23T09:09:41-04:00
EPA Some tweaks to annotations

- Fix span for GRHS
- Move TrailingAnns from last match to FunBind
- Fix GADT 'where' clause span
- Capture full range for a CaseAlt Match

- - - - -
d5a8780d by Simon Hengel at 2023-10-23T09:10:23-04:00
Update primitives.rst
- - - - -
4d075924 by Josh Meredith at 2023-10-24T23:04:12+11:00
JS/userguide: add explanation of writing jsbits

- - - - -
07ab5cc1 by Cheng Shao at 2023-10-24T15:40:32-04:00
testsuite: increase timeout of ghc-api tests for wasm32

ghc-api tests for wasm32 are more likely to timeout due to the large
wasm module sizes, especially when testing with wasm native tail
calls, given wasmtime's handling of tail call opcodes are suboptimal
at the moment. It makes sense to increase timeout specifically for
these tests on wasm32. This doesn't affect other targets, and for
wasm32 we don't increase timeout for all tests, so not to risk letting
major performance regressions slip through the testsuite.

- - - - -
0d6acca5 by Greg Steuck at 2023-10-26T08:44:23-04:00
Explicitly require RLIMIT_AS before use in OSMem.c

This is done elsewhere in the source tree. It also suddenly is
required on OpenBSD.

- - - - -
9408b086 by Sylvain Henry at 2023-10-26T08:45:03-04:00
Modularity: modularize external linker

Decouple runLink from DynFlags to allow calling runLink more easily.
This is preliminary work for calling Emscripten's linker (emcc) from
our JavaScript linker.

- - - - -
e0f35030 by doyougnu at 2023-10-27T08:41:12-04:00
js: add JStg IR, remove unsaturated constructor

- Major step towards #22736 and adding the optimizer in #22261

- - - - -
35587eba by Simon Peyton Jones at 2023-10-27T08:41:48-04:00
Fix a bug in tail calls with ticks

See #24078 for the diagnosis.  The change affects only
the Tick case of occurrence analysis.

It's a bit hard to test, so no regression test (yet anyway).

- - - - -
e01576f0 by Ryan Scott at 2023-10-27T20:31:36+00:00
More robust checking for DataKinds

As observed in #22141, GHC was not doing its due diligence in catching code
that should require `DataKinds` in order to use. Most notably, it was allowing
the use of arbitrary data types in kind contexts without `DataKinds`, e.g.,

```hs
data Vector :: Nat -> Type -> Type where
```

This patch revamps how GHC tracks `DataKinds`. The full specification is
written out in the `DataKinds` section of the GHC User's Guide, and the
implementation thereof is described in `Note [Checking for DataKinds]` in
`GHC.Tc.Validity`. In brief:

* We catch _type_-level `DataKinds` violations in the renamer. See
  `checkDataKinds` in `GHC.Rename.HsType` and `check_data_kinds` in
  `GHC.Rename.Pat`.

* We catch _kind_-level `DataKinds` violations in the typechecker, as this
  allows us to catch things that appear beneath type synonyms. (We do *not*
  want to do this in type-level contexts, as it is perfectly fine for a type
  synonym to mention something that requires DataKinds while still using the
  type synonym in a module that doesn't enable DataKinds.) See `checkValidType`
  in `GHC.Tc.Validity`.

* There is now a single `TcRnDataKindsError` that classifies all manner of
  `DataKinds` violations, both in the renamer and the typechecker. The
  `NoDataKindsDC` error has been removed, as it has been subsumed by
  `TcRnDataKindsError`.

* I have added `CONSTRAINT` is `isKindTyCon`, which is what checks for illicit
  uses of data types at the kind level without `DataKinds`. Previously,
  `isKindTyCon` checked for `Constraint` but not `CONSTRAINT`. This is
  inconsistent, given that both `Type` and `TYPE` were checked by `isKindTyCon`.
  Moreover, it thwarted the implementation of the `DataKinds` check in
  `checkValidType`, since we would expand `Constraint` (which was OK without
  `DataKinds`) to `CONSTRAINT` (which was _not_ OK without `DataKinds`) and
  reject it. Now both are allowed.

* I have added a flurry of additional test cases that test various corners of
  `DataKinds` checking.

Fixes #22141.

- - - - -


25 changed files:

- .ghcid
- .gitignore
- compiler/GHC/Builtin/primops.txt.pp
- compiler/GHC/ByteCode/Asm.hs
- compiler/GHC/Core/Opt/OccurAnal.hs
- compiler/GHC/Core/TyCon.hs
- compiler/GHC/CoreToStg/Prep.hs
- compiler/GHC/Data/OrdList.hs
- compiler/GHC/Driver/Config/Linker.hs
- compiler/GHC/Driver/Flags.hs
- compiler/GHC/Driver/Session.hs
- + compiler/GHC/JS/Ident.hs
- + compiler/GHC/JS/JStg/Monad.hs
- compiler/GHC/JS/Unsat/Syntax.hs → compiler/GHC/JS/JStg/Syntax.hs
- compiler/GHC/JS/Make.hs
- compiler/GHC/JS/Ppr.hs
- compiler/GHC/JS/Syntax.hs
- compiler/GHC/JS/Transform.hs
- compiler/GHC/Linker/Config.hs
- compiler/GHC/Linker/Dynamic.hs
- + compiler/GHC/Linker/External.hs
- compiler/GHC/Linker/Static.hs
- compiler/GHC/Parser.y
- compiler/GHC/Parser/Annotation.hs
- compiler/GHC/Parser/PostProcess.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/ed5215cd4cd2d3263e6c307c23d7d7dd9c2db6dc...e01576f0897de1007374e6c51c1d441054340c7d

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/ed5215cd4cd2d3263e6c307c23d7d7dd9c2db6dc...e01576f0897de1007374e6c51c1d441054340c7d
You're receiving this email because of your account on gitlab.haskell.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20231027/628e7c09/attachment-0001.html>


More information about the ghc-commits mailing list