[Git][ghc/ghc][wip/expand-do] 32 commits: Test that functions from `mingwex` are available
Apoorv Ingle (@ani)
gitlab at gitlab.haskell.org
Thu Oct 19 18:26:40 UTC 2023
Apoorv Ingle pushed to branch wip/expand-do at Glasgow Haskell Compiler / GHC
Commits:
34fc28b0 by John Ericson at 2023-10-12T06:48:28-04:00
Test that functions from `mingwex` are available
Ryan wrote these two minimizations, but they never got added to the test
suite.
See #23309, #23378
Co-Authored-By: Ben Gamari <bgamari.foss at gmail.com>
Co-Authored-By: Ryan Scott <ryan.gl.scott at gmail.com>
- - - - -
bdb54a0e by John Ericson at 2023-10-12T06:48:28-04:00
Do not check for the `mingwex` library in `/configure`
See the recent discussion in !10360 --- Cabal will itself check for the
library for the packages that need it, and while the autoconf check
additionally does some other things like define a `HAS_LIBMINGWEX` C
Preprocessor macro, those other things are also unused and unneeded.
Progress towards #17191, which aims to get rid of `/configure` entirely.
- - - - -
43e814e1 by Ben Gamari at 2023-10-12T06:49:40-04:00
base: Introduce move modules into src
The only non-move changes here are whitespace changes to pass the
`whitespace` test and a few testsuite adaptations.
- - - - -
df81536f by Moritz Angermann at 2023-10-12T06:50:16-04:00
[PEi386 linker] Bounds check and null-deref guard
We should resonably be able to expect that we won't exceed the number of
sections if we assume to be dealing with legal object files. We can however
not guarantee that we get some negative values, and while we try to
special case most, we should exclude negative indexing into the sections
array.
We also need to ensure that we do not try to derefences targetSection,
if it is NULL, due to the switch statement.
- - - - -
c74c4f00 by John Ericson at 2023-10-12T10:31:13-04:00
Move apple compat check to RTS configure
- - - - -
c80778ea by John Ericson at 2023-10-12T10:31:13-04:00
Move clock/timer fun checks to RTS configure
Actual library check (which will set the Cabal flag) is left in the
top-level configure for now.
Progress towards #17191
- - - - -
7f9f2686 by John Ericson at 2023-10-12T10:31:13-04:00
Move visibility and "musttail" annotation checks to the RTS configure
All of this should boil down to `AC_DEFINE` not `AC_SUBST`, so it
belongs in the RTS configure and should be safe to move without
modification.
Progress towards #17191
- - - - -
ffb3efe6 by John Ericson at 2023-10-12T10:31:13-04:00
Move leading underscore checks to RTS configure
`CabalLeadingUnderscore` is done via Hadrian already, so we can stop
`AC_SUBST`ing it completely.
- - - - -
25fa4b02 by John Ericson at 2023-10-12T10:31:13-04:00
Move alloca, fork, const, and big endian checks to RTS configure
All of this should boil down to `AC_DEFINE` not `AC_SUBST`, so it
belongs in the RTS configure and should be safe to move without
modification.
- - - - -
5170f42a by John Ericson at 2023-10-12T10:31:13-04:00
Move libdl check to RTS configure
- - - - -
ea7a1447 by John Ericson at 2023-10-12T10:31:13-04:00
Adjust `FP_FIND_LIBFFI`
Just set vars, and `AC_SUBST` in top-level configure.
Don't define `HAVE_SYSTEM_LIBFFI` because nothing is using it. It hasn't
be in used since 3609340743c1b25fdfd0e18b1670dac54c8d8623 (part of the
make build system).
- - - - -
f399812c by John Ericson at 2023-10-12T10:31:13-04:00
Split BFD support to RTS configure
The flag is still in the top-level configure, but the other checks
(which define various macros --- important) are in the RTS configure.
- - - - -
f64f44e9 by John Ericson at 2023-10-12T10:31:13-04:00
Split libm check between top level and RTS
- - - - -
dafc4709 by Moritz Angermann at 2023-10-12T10:31:49-04:00
CgUtils.fixStgRegStmt respect register width
This change ensure that the reg + offset computation is always of the
same size. Before this we could end up with a 64bit register, and then
add a 32bit offset (on 32bit platforms). This not only would fail type
sanity checking, but also incorrectly truncate 64bit values into 32bit
values silently on 32bit architectures.
- - - - -
9e6ef7ba by Matthew Pickering at 2023-10-12T20:35:00-04:00
hadrian: Decrease verbosity of cabal commands
In Normal, most tools do not produce output to stdout unless there are
error conditions.
Reverts 7ed65f5a1bc8e040e318ccff395f53a9bbfd8217
- - - - -
08fc27af by John Ericson at 2023-10-12T20:35:36-04:00
Do not substitute `@...@` for stage-specific values in cabal files
`rts` and `ghc-prim` now no longer have a `*.cabal.in` to set Cabal flag
defaults; instead manual choices are passed to configure in the usual
way.
The old way was fundamentally broken, because it meant we were baking
these Cabal files for a specific stage. Now we only do stage-agnostic
@...@ substitution in cabal files (the GHC version), and so all
stage-specific configuration is properly confined to `_build` and the
right stage dir.
Also `include-ghc-prim` is a flag that no longer exists for `ghc-prim`
(it was removed in 835d8ddbbfb11796ea8a03d1806b7cee38ba17a6) so I got
rid of it.
Co-Authored-By: Matthew Pickering <matthewtpickering at gmail.com>
- - - - -
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
- - - - -
21cdbe23 by Apoorv Ingle at 2023-10-19T13:25:46-05:00
Expand `do` blocks right before typechecking using the `HsExpansion` philosophy.
- A step towards killing `tcSyntaxOp`
- Fixes #18324 #20020 #23147 #22788 #15598 #22086 #21206
- Note [Expanding HsDo with HsExpansion] in `GHC.Tc.Gen.Do` explains change in detail
- Note Note [Doing HsExpansion in the Renamer vs Typechecker] in `GHC.Rename.Expr` expains the rational of doing expansions in type checker as opposed to in the renamer
- New datatype to make this expansion work `GHC.Hs.Expr.XXExprGhcRn`:
1. Expansion bits for Expressions, Statements and Patterns in (`ExpandedThingRn`)
2. `PopErrCtxt` a special GhcRn Phase only artifcat to pop the previous error message in the error context stack
- Kills `HsExpansion` and `HsExpanded` as we have inlined them in `XXExprGhcRn` and `XXExprGhcTc`
- `GHC.Basic.Origin` now tracks the reason for expansion in case of Generated
This is useful for type checking cf. `GHC.Tc.Gen.Expr.tcExpr` case for `HsLam`
- Ensures warnings such as
1. Pattern mach checks
2. Failable patterns
3. non-() return in body statements are preserved
- Expansions inside Template haskell also work without issues.
- Testcases:
* T18324 T20020 T23147 T22788 T15598 T22086
* T23147b (error message check),
* DoubleMatch (match inside a match for pmc check)
* pattern-fails (check pattern match with non-refutable pattern, eg. newtype)
* Simple-rec (rec statements inside do statment)
* T22788 (code snippet from #22788)
* DoExpanion1 (Error messages for body statments)
* DoExpansion2 (Error messages for bind statements)
* DoExpansion3 (Error messages for let statements)
- - - - -
26 changed files:
- .ghcid
- .gitignore
- compiler/GHC/CoreToStg/Prep.hs
- compiler/GHC/Data/OrdList.hs
- compiler/GHC/Hs/Expr.hs
- compiler/GHC/Hs/Instances.hs
- compiler/GHC/Hs/Pat.hs
- compiler/GHC/Hs/Syn/Type.hs
- compiler/GHC/Hs/Utils.hs
- compiler/GHC/HsToCore/Arrows.hs
- compiler/GHC/HsToCore/Expr.hs
- compiler/GHC/HsToCore/Match.hs
- compiler/GHC/HsToCore/Pmc.hs
- compiler/GHC/HsToCore/Quote.hs
- compiler/GHC/HsToCore/Ticks.hs
- compiler/GHC/Iface/Ext/Ast.hs
- compiler/GHC/Rename/Env.hs
- compiler/GHC/Rename/Expr.hs
- compiler/GHC/Rename/Names.hs
- compiler/GHC/Rename/Pat.hs
- compiler/GHC/Rename/Utils.hs
- compiler/GHC/StgToCmm/CgUtils.hs
- compiler/GHC/Tc/Deriv/Generate.hs
- compiler/GHC/Tc/Errors/Ppr.hs
- compiler/GHC/Tc/Gen/App.hs
- + compiler/GHC/Tc/Gen/Do.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/e8bdbd78f102e72b33208a491c7d33c1b7f43397...21cdbe23764d15fe132d499a95817bdbdb942ad6
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/e8bdbd78f102e72b33208a491c7d33c1b7f43397...21cdbe23764d15fe132d499a95817bdbdb942ad6
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/20231019/8faf71ce/attachment-0001.html>
More information about the ghc-commits
mailing list