[Git][ghc/ghc][wip/cabal-3.14] 15 commits: Handle exceptions from IO manager backend

Zubin (@wz1000) gitlab at gitlab.haskell.org
Fri Oct 11 07:59:00 UTC 2024



Zubin pushed to branch wip/cabal-3.14 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

- - - - -
465cb564 by Zubin Duggal at 2024-10-11T07:58:57+00:00
hadrian: Handle broken symlinks properly when creating source dist directories

If we have a broken symlink in the repository, don't try to `need` the symlink
or the target of the symlink. Attempting to do so has `shake` attempt to read the
target to compute its hash, which fails because the target doesn't exist.

- - - - -
05bcb67c by Zubin Duggal at 2024-10-11T07:58:57+00:00
hadrian: exclude cabal.project.symlink.broken from source archives

Cabal 3.14 introduced a broken symlink in its testsuite. Unfortunately,
this broke our source distribution as we use use `tar --dereference` to avoid
issues with symlink compatibility on windows, and `tar --dereference` chokes
when it encounters any broken symlinks.

We can't get rid of `--dereference` because symlinks are generally broken on
windows, so the only option is to exclude this file from source archives.

see also https://github.com/haskell/cabal/issues/10442

- - - - -
e127d3da by Zubin Duggal at 2024-10-11T07:58:57+00:00
Bump Cabal submodule to 3.14

Metric Increase:
    haddock.Cabal

- - - - -


30 changed files:

- compiler/GHC/Driver/Errors/Ppr.hs
- compiler/GHC/Driver/Errors/Types.hs
- compiler/GHC/Driver/Pipeline/Execute.hs
- compiler/GHC/Hs/Binds.hs
- + compiler/GHC/Hs/Doc.hs-boot
- compiler/GHC/Hs/Expr.hs
- compiler/GHC/Hs/Extension.hs
- compiler/GHC/Hs/Instances.hs
- compiler/GHC/Hs/Pat.hs
- compiler/GHC/Hs/Syn/Type.hs
- compiler/GHC/Hs/Type.hs
- compiler/GHC/Hs/Utils.hs
- compiler/GHC/HsToCore/Docs.hs
- compiler/GHC/HsToCore/Expr.hs
- compiler/GHC/HsToCore/Quote.hs
- compiler/GHC/HsToCore/Ticks.hs
- compiler/GHC/Iface/Ext/Ast.hs
- compiler/GHC/Parser/PostProcess.hs
- compiler/GHC/Rename/Bind.hs
- compiler/GHC/Rename/Env.hs
- compiler/GHC/Rename/Expr.hs
- compiler/GHC/Rename/Fixity.hs
- compiler/GHC/Rename/HsType.hs
- compiler/GHC/Rename/Pat.hs
- compiler/GHC/SysTools/Tasks.hs
- compiler/GHC/Tc/Errors.hs
- compiler/GHC/Tc/Gen/Expr.hs
- compiler/GHC/Tc/Gen/Head.hs
- compiler/GHC/Tc/Gen/Pat.hs
- compiler/GHC/Tc/TyCl/Utils.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/50ec8c4ab9db8d0bec202b44a5075790bb45e9eb...e127d3da421e3bab0907db350c23ce1103c78320

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/50ec8c4ab9db8d0bec202b44a5075790bb45e9eb...e127d3da421e3bab0907db350c23ce1103c78320
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/7f9e232c/attachment-0001.html>


More information about the ghc-commits mailing list