[Git][ghc/ghc][wip/backports] 9 commits: FastString: fix eager reading of string ptr in hashStr

Ben Gamari gitlab at gitlab.haskell.org
Thu May 14 16:51:05 UTC 2020 


Ben Gamari pushed to branch wip/backports at Glasgow Haskell Compiler / GHC


Commits:
8b2e2c5d by Ömer Sinan Ağacan at 2020-05-14T12:31:10-04:00
FastString: fix eager reading of string ptr in hashStr

This read causes NULL dereferencing when len is 0.

Fixes #17909

In the reproducer in #17909 this bug is triggered as follows:

- SimplOpt.dealWithStringLiteral is called with a single-char string
  ("=" in #17909)

- tailFS gets called on the FastString of the single-char string.

- tailFS checks the length of the string, which is 1, and calls
  mkFastStringByteString on the tail of the ByteString, which is an
  empty ByteString as the original ByteString has only one char.

- ByteString's unsafeUseAsCStringLen returns (NULL, 0) for the empty
  ByteString, which is passed to mkFastStringWith.

- mkFastStringWith gets hash of the NULL pointer via hashStr, which
  fails on empty strings because of this bug.

(cherry picked from commit d15b61608a542f6349b42224140b7d227b88ef4e)

- - - - -
feabe4bd by Simon Peyton Jones at 2020-05-14T12:34:39-04:00
Improve error handling for VTA + deferred type errors

This fixes #17792

See Note [VTA for out-of-scope functions] in TcExpr

(cherry picked from commit 335b18bac3c361d243f427b66e67c2c94f5c6494)

- - - - -
fbf280c2 by Simon Peyton Jones at 2020-05-14T12:38:20-04:00
Add a missing zonk in tcHsPartialType

I omitted a vital zonk when refactoring tcHsPartialType in
   commit 48fb3482f8cbc8a4b37161021e846105f980eed4
   Author: Simon Peyton Jones <simonpj at microsoft.com>
   Date:   Wed Jun 5 08:55:17 2019 +0100

   Fix typechecking of partial type signatures

This patch fixes it and adds commentary to explain why.

Fixes #18008

(cherry picked from commit 658bda511237593bb80389280d0364180648058d)

- - - - -
3d9267f2 by Sylvain Henry at 2020-05-14T12:39:04-04:00
Rts: show errno on failure (#18033)

(cherry picked from commit 4875d419ba066e479f7ac07f8b39ebe10c855859)

- - - - -
1ad5f9d3 by Simon Peyton Jones at 2020-05-14T12:48:31-04:00
Major improvements to the specialiser

This patch is joint work of Alexis King and Simon PJ.  It does some
significant refactoring of the type-class specialiser.  Main highlights:

* We can specialise functions with types like
     f :: Eq a => a -> Ord b => b => blah
  where the classes aren't all at the front (#16473).  Here we can
  correctly specialise 'f' based on a call like
     f @Int @Bool dEqInt x dOrdBool
  This change really happened in an earlier patch
     commit 2d0cf6252957b8980d89481ecd0b79891da4b14b
     Author: Sandy Maguire <sandy at sandymaguire.me>
     Date:   Thu May 16 12:12:10 2019 -0400
  work that this new patch builds directly on that work, and refactors
  it a bit.

* We can specialise functions with implicit parameters (#17930)
     g :: (?foo :: Bool, Show a) => a -> String
  Previously we could not, but now they behave just like a non-class
  argument as in 'f' above.

* We can specialise under-saturated calls, where some (but not all of
  the dictionary arguments are provided (#17966).  For example, we can
  specialise the above 'f' based on a call
     map (f @Int dEqInt) xs
  even though we don't (and can't) give Ord dictionary.

  This may sound exotic, but #17966 is a program from the wild, and
  showed significant perf loss for functions like f, if you need
  saturation of all dictionaries.

* We fix a buglet in which a floated dictionary had a bogus demand
  (#17810), by using zapIdDemandInfo in the NonRec case of specBind.

* A tiny side benefit: we can drop dead arguments to specialised
  functions; see Note [Drop dead args from specialisations]

* Fixed a bug in deciding what dictionaries are "interesting"; see
  Note [Keep the old dictionaries interesting]

This is all achieved by by building on Sandy Macguire's work in
defining SpecArg, which mkCallUDs uses to describe the arguments of
the call. Main changes:

* Main work is in specHeader, which marched down the [InBndr] from the
  function definition and the [SpecArg] from the call site, together.

* specCalls no longer has an arity check; the entire mechanism now
  handles unders-saturated calls fine.

* mkCallUDs decides on an argument-by-argument basis whether to
  specialise a particular dictionary argument; this is new.
  See mk_spec_arg in mkCallUDs.

It looks as if there are many more lines of code, but I think that
all the extra lines are comments!

(cherry picked from commit 7052d7c7ce3418db9e66ad6ff31e80b2a2c724bb)

- - - - -
0e15cd02 by Ryan Scott at 2020-05-14T12:48:43-04:00
Fix two ASSERT buglets in reifyDataCon

Two `ASSERT`s in `reifyDataCon` were always using `arg_tys`, but
`arg_tys` is not meaningful for GADT constructors. In fact, it's
worse than non-meaningful, since using `arg_tys` when reifying a
GADT constructor can lead to failed `ASSERT`ions, as #17305
demonstrates.

This patch applies the simplest possible fix to the immediate
problem. The `ASSERT`s now use `r_arg_tys` instead of `arg_tys`, as
the former makes sure to give something meaningful for GADT
constructors. This makes the panic go away at the very least. There
is still an underlying issue with the way the internals of
`reifyDataCon` work, as described in
https://gitlab.haskell.org/ghc/ghc/issues/17305#note_227023, but we
leave that as future work, since fixing the underlying issue is
much trickier (see
https://gitlab.haskell.org/ghc/ghc/issues/17305#note_227087).

(cherry picked from commit cfb66d181ac45ce3d934bda3521b94277e6eb683)

- - - - -
522fb66e by Adam Gundry at 2020-05-14T12:50:21-04:00
Reject all duplicate declarations involving DuplicateRecordFields (fixes #17965)

This fixes a bug that resulted in some programs being accepted that used the same
identifier as a field label and another declaration, depending on the order they
appeared in the source code.

(cherry picked from commit 0d8c7a6c7c3513089668f49efb0a2dd8b4bbe74a)

- - - - -
9e50a165 by Ben Gamari at 2020-05-14T12:50:34-04:00
Ensure that printMinimalImports closes handle

Fixes #18166.

(cherry picked from commit 5afc160dee7142c96a842037fb64bee1429ad9ec)

- - - - -
c54556ec by Ben Gamari at 2020-05-14T12:50:48-04:00
rts: Make non-existent linker search path merely a warning

As noted in #18105, previously this resulted in a rather intrusive error
message. This is in contrast to the general expectation that search
paths are merely places to look, not places that must exist.

Fixes #18105.

(cherry picked from commit 24af9f30681444380c25465f555599da563713cb)

- - - - -


30 changed files:

- compiler/basicTypes/RdrName.hs
- compiler/coreSyn/CoreSubst.hs
- compiler/coreSyn/CoreUnfold.hs
- compiler/deSugar/DsBinds.hs
- compiler/rename/RnNames.hs
- compiler/specialise/Specialise.hs
- compiler/typecheck/TcExpr.hs
- compiler/typecheck/TcHsType.hs
- compiler/typecheck/TcSplice.hs
- compiler/utils/FastString.hs
- rts/linker/PEi386.c
- rts/posix/itimer/Pthread.c
- + testsuite/tests/overloadedrecflds/should_fail/T17965.hs
- + testsuite/tests/overloadedrecflds/should_fail/T17965.stderr
- testsuite/tests/overloadedrecflds/should_fail/all.T
- + testsuite/tests/partial-sigs/should_compile/T18008.hs
- + testsuite/tests/partial-sigs/should_compile/T18008.stderr
- testsuite/tests/partial-sigs/should_compile/all.T
- testsuite/tests/perf/compiler/T16473.stdout
- testsuite/tests/simplCore/should_compile/Makefile
- + testsuite/tests/simplCore/should_compile/T17810.hs
- + testsuite/tests/simplCore/should_compile/T17810a.hs
- + testsuite/tests/simplCore/should_compile/T17930.hs
- + testsuite/tests/simplCore/should_compile/T17930.stderr
- + testsuite/tests/simplCore/should_compile/T17966.hs
- + testsuite/tests/simplCore/should_compile/T17966.stdout
- testsuite/tests/simplCore/should_compile/all.T
- + testsuite/tests/simplCore/should_compile/spec004.hs
- + testsuite/tests/simplCore/should_compile/spec004.stderr
- + testsuite/tests/th/T17305.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/b9df14c49bd6b70e403559e9a70669cc50d7e2f8...c54556ec1a6864b620d7eafcc10a7f55ac0c69b1

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/b9df14c49bd6b70e403559e9a70669cc50d7e2f8...c54556ec1a6864b620d7eafcc10a7f55ac0c69b1
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/20200514/9c3d83d1/attachment-0001.html>

More information about the ghc-commits mailing list