[Git][ghc/ghc][wip/T25281] 14 commits: Handle exceptions from IO manager backend
Simon Peyton Jones (@simonpj)
gitlab at gitlab.haskell.org
Fri Oct 11 15:39:10 UTC 2024
Simon Peyton Jones pushed to branch wip/T25281 at Glasgow Haskell Compiler / GHC
Commits:
69960230 by Fabian Thorand at 2024-10-10T19:03:59+00:00
Handle exceptions from IO manager backend
If an IO manager backend throws, it will not actually have registered
the file descriptor. However, at that point, the IO manager state was
already updated to assume the file descriptor is being tracked, leading
to errors and an eventual deadlock down the line as documented in the
issue #21969.
The fix for this is to undo the IO manager state change in case the
backend throws (just as we already do when the backend signals that the
file type is not supported). The exception then bubbles up to user code.
That way we make sure that
1. the bookkeeping state of the IO manager is consistent with the
actions taken by the backend, even in the presence of unexpected
failures, and
2. the error is not silent and visible to user code, making failures
easier to debug.
- - - - -
1587cccf by Hassan Al-Awwadi at 2024-10-11T03:52:36-04:00
Put RdrName in the foExt field of FieldOcc
The main purpose of this commit is to rip RdrName out of FieldOcc, in
accordance with #21592, and as a side note it has simplified the method
we use to deal with ambiguity somewhat.
To do the first, we make FieldOccs store (LIdP p) instead of always
storing Located RdrName, and moved the readername to the extension
points where necessary.
For the second, well, we just turn an ambiguous RdrName into a unbound
Name through mkUnboundName. Later during disambiguateRecordBinds of the
type checking phase, we will try and do type-directed disambiguation based
on the rdrName field (for now), so this hack works out fine.
See Note [Ambiguous FieldOcc in record updates] for more details.
There are two additional minor changes in this commit:
* The HsRecSel constructor of HsExpr has been moved to the extension
constuctors, since its really GHC specific.
* HsProjection no longer has a Located DotFieldOcc as a field, but just a
regular DotFieldOcc, since DotFieldOcc already wraps a located
FieldLabelString
co-authored by: @Jade <Jade512 at proton.me>
@alt-romes <rodrigo.m.mesquita at gmail.com>
- - - - -
2338a971 by Cheng Shao at 2024-10-11T03:53:13-04:00
driver: bail out when -fllvm is passed to GHC not configured with LLVM
This patch makes GHC bail out with an proper error message when it's
not configured with LLVM but users attempt to pass -fllvm, see #25011
and added comment for details.
Fixes #25011
Co-authored-by: Rodrigo Mesquita <rodrigo.m.mesquita at gmail.com>
- - - - -
78ad81ec by Cristiano Moraes at 2024-10-11T03:53:55-04:00
configure: Find C++ probing when GCC version is the latest but G++ is old #23118
- - - - -
083703a1 by Simon Peyton Jones at 2024-10-11T03:54:32-04:00
Consider Wanteds with rewriters as insoluble
This MR fixes #25325
See GHC.Tc.Types.Constraint, Note [Insoluble Wanteds], especially (IW2)
There is a small change in the error message for T14172, but it looks
entirely acceptable to me.
- - - - -
0dfaeb66 by Simon Peyton Jones at 2024-10-11T03:54:32-04:00
Wibbles
- - - - -
09d24d82 by Simon Peyton Jones at 2024-10-11T03:54:32-04:00
Spelling errors
- - - - -
694489ed by sheaf at 2024-10-11T03:55:14-04:00
LLVM: use sse4.2 instead of sse42
LLVM expects the former instead of the latter since version 3.4.
Fixes #25019
- - - - -
06ae8507 by sheaf at 2024-10-11T03:55:14-04:00
LLVM: make SSE4.2 imply +popcnt
For consistency with the NCG as well as with Clang and GCC, we make
the SSE4.2 feature flag imply +popcnt when using the LLVM backend.
Fixes #25353
- - - - -
3fe843c7 by Cheng Shao at 2024-10-11T03:55:50-04:00
Drop obsolete libffi Makefile
This patch drops obsolete libffi Makefile from the tree, given it's
completely unused since removal of make build system in !7094.
- - - - -
df70405c by Ben Gamari at 2024-10-11T03:56:26-04:00
ghc-internal: Fix incomplete matches on IOError
As noted in #25362, these incomplete matches were previously not being
warned about. They were easily addressed by use of
`GHC.Internal.Event.Windows.withException`.
Closes #25362.
- - - - -
8584504b by Matthew Pickering at 2024-10-11T03:57:02-04:00
compiler: Fix orientation of GHC.Hs.Doc boot file
We should be free to import things from Language.Haskell.Syntax in GHC
modules. Therefore the the boot file for the loop between ImpExp and
GHC.Hs.Doc was in the wrong place.
Issue #21592
- - - - -
d660dcb6 by Sebastian Graf at 2024-10-11T16:38:18+01:00
Desugaring, plus -Wincomplete-record-selectors
This commit does several related things:
* Major refactor of the handling of applications in the desugarer.
Now all applications are handled in `dsApp`, `ds_app` and related
functions. This dramatically simplifies the code and removes
complicated cruft that had accumulated. Hooray.
Fixes #25281.
* Improve the handling of -Wincomplete-record-selectors.
We now incorporate the result type of unsaturated record selector
applications as well as consider long-distance information in
getField applications.
Plus, the implmentation now builds the improved `dsApp` stuff
above, so it is much easier to understand.
Plus, incorporates improved error message wording suggested
by Adam Gundry in !12685.
Fixes #24824, #24891
See the long Note [Detecting incomplete record selectors]
* Add -Wincomplete-record-selectors to -Wall, as specified in
GHC Proposal 516.
To do this, I also had to add -Wno-incomplete-record-selectors
to the build flags for Cabal in GHC's CI. See
hadrian/src/Settings/Warnings.hs. We can remove this when
Cabal is updated so that it doesn't trigger the warning:
https://github.com/haskell/cabal/issues/10402
2.6% decrease in compile time allocation in RecordUpPerf
Metric Decrease:
RecordUpdPerf
- - - - -
fe5d8e3c by Simon Peyton Jones at 2024-10-11T16:38:25+01:00
Elmininate incomplete record selectors
This patch is a pure refactor of GHC's source code, to avoid the use
of partial record selectors. It was provoked by adding
-Wincomplete-record-selectors to -Wall (as the GHC Proposal specified),
which in turn showed up lots of places where GHC was using incomplete
record selectors.
This patch does mostly-simple refactoring to make it clear to the pattern
match checker that there is in fact no partiality.
There is one externally-visible change: I changed the data type HoleFit
to split out the two cases
data HoleFit = TcHoleFit TcHoleFit | RawHoleFit SDoc
data TcHoleFit = HoleFit { ...lots of fields }
There are large swathes of code that just deal with `TcHoleFit`, and
having it as a separate data types makes it apparent that `RawHoleFit`
can't occur.
This makes it much better -- but the change is visible in the
HolePlugin interface. I decided that there are so few clients of this
API that it's worth the change.
I moved several functions from Language.Haskell.Syntax to GHC.Hs.
Reason, when instantiated at (GhcPass _), the extension data construtcor
is guaranteed unused, and that justifies omitted patterns in these
functions. By putting them in GHC.Hs.X I can specialise the type for
(GhcPass _) and thereby make the function total.
An interesting side-light is that there were a few local function
definitions without a type signature, like this one in GHC.Parser.Header
convImport (L _ i) = (ideclPkgQual i, reLoc $ ideclName i)
This is fully closed, and so is generalised; but that generalises
it to any old pass, not (GhcPass _), so GHC rightly complains about the
use of the selector `ideclPkgQual`. I added a type signature to `i`, thus
convImport (L _ (i::ImportDecl GhcPs))
= (ideclPkgQual i, reLoc $ ideclName i)
which specialised the function enough to make the record selector complete.
Quite a surprising consequence of local let-generalisation!
- - - - -
30 changed files:
- compiler/GHC/CmmToAsm/Dwarf/Types.hs
- compiler/GHC/CmmToAsm/Reg/Graph/Stats.hs
- compiler/GHC/Core.hs
- compiler/GHC/Core/Coercion.hs
- compiler/GHC/Core/ConLike.hs
- compiler/GHC/Core/FVs.hs
- compiler/GHC/Core/LateCC/OverloadedCalls.hs
- compiler/GHC/Core/Lint.hs
- compiler/GHC/Core/Opt/Arity.hs
- compiler/GHC/Core/Opt/CprAnal.hs
- compiler/GHC/Core/Opt/DmdAnal.hs
- compiler/GHC/Core/Opt/Simplify/Env.hs
- compiler/GHC/Core/Opt/Simplify/Utils.hs
- compiler/GHC/Core/Opt/SpecConstr.hs
- compiler/GHC/Core/Rules.hs
- compiler/GHC/Core/SimpleOpt.hs
- compiler/GHC/Core/Subst.hs
- compiler/GHC/Core/Type.hs
- compiler/GHC/Core/Utils.hs
- compiler/GHC/CoreToIface.hs
- compiler/GHC/Driver/Errors/Ppr.hs
- compiler/GHC/Driver/Errors/Types.hs
- compiler/GHC/Driver/Flags.hs
- compiler/GHC/Driver/Pipeline/Execute.hs
- compiler/GHC/Hs/Binds.hs
- compiler/GHC/Hs/Decls.hs
- + compiler/GHC/Hs/Doc.hs-boot
- compiler/GHC/Hs/Expr.hs
- compiler/GHC/Hs/Extension.hs
- compiler/GHC/Hs/Instances.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/de030c0b6096a2696f863d1b07151c607ee7a4e0...fe5d8e3cfe5d3399c2c12774f444a1c7b82a3b99
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/de030c0b6096a2696f863d1b07151c607ee7a4e0...fe5d8e3cfe5d3399c2c12774f444a1c7b82a3b99
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/20241011/d8c6e8d0/attachment-0001.html>
More information about the ghc-commits
mailing list