#7672: boot file entities are sometimes invisible and are not (semantically)
unified with corresponding entities in implementing module
-------------------------------------+-------------------------------------
Reporter: skilpat | Owner: ezyang
Type: bug | Status: new
Priority: normal | Milestone: 7.12.1
Component: Compiler (Type | Version: 7.4.2
checker) | Keywords: backpack
Resolution: | Architecture: x86_64
Operating System: Linux | (amd64)
Type of failure: GHC rejects | Test Case:
valid program | rename/should_compile/T7672
Blocked By: | Blocking: 10336
Related Tickets: | Differential Revisions:
-------------------------------------+-------------------------------------
Changes (by simonpj):
* testcase: T7672 => rename/should_compile/T7672
Comment:
Despite all this clean up, the test for #7672 ''still'' does not work.
Reason: in module A (comment:3), the data type `T` is in scope with two
different provenances:
* As `LocalDef` "T"
* As `Imported` "B.T"
But annoyingly, `Provenance` can't represent both; currently it's an
either/or.
Fixing this really means changing the `Provenance` data type.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7672#comment:16>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#10423: Can't infer Monad n from (Monad m, m ~ n)
-------------------------------------+-------------------------------------
Reporter: Feuerbach | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.11
(Type checker) | Operating System: Unknown/Multiple
Keywords: | Type of failure: None/Unknown
Architecture: | Blocked By:
Unknown/Multiple | Related Tickets:
Test Case: |
Blocking: |
Differential Revisions: |
-------------------------------------+-------------------------------------
This looks like a regression in GHC HEAD.
{{{
Test/SmallCheck/Property.hs:187:10:
Could not deduce (Monad n)
arising from the superclasses of an instance declaration
from the context: (Monad m, m ~ n)
bound by the instance declaration
at Test/SmallCheck/Property.hs:187:10-52
Possible fix:
add (Monad n) to the context of the instance declaration
In the instance declaration for ‘Testable n (Property m)’
}}}
The code is here:
https://github.com/feuerbach/smallcheck/blob/v1.1.1/Test/SmallCheck/Propert…
Originally reported here:
https://github.com/feuerbach/smallcheck/issues/28
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10423>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7672: boot file entities are sometimes invisible and are not (semantically)
unified with corresponding entities in implementing module
-------------------------------------+-------------------------------------
Reporter: skilpat | Owner: ezyang
Type: bug | Status: new
Priority: normal | Milestone: 7.12.1
Component: Compiler (Type | Version: 7.4.2
checker) | Keywords: backpack
Resolution: | Architecture: x86_64
Operating System: Linux | (amd64)
Type of failure: GHC rejects | Test Case: T7672
valid program | Blocking: 10336
Blocked By: | Differential Revisions:
Related Tickets: |
-------------------------------------+-------------------------------------
Comment (by Simon Peyton Jones <simonpj@…>):
In [changeset:"9b73cb16485f331d9dc1f37826c6d503e24a5b0b/ghc"]:
{{{
#!CommitTicketReference repository="ghc"
revision="9b73cb16485f331d9dc1f37826c6d503e24a5b0b"
Refactor the GlobalRdrEnv, fixing #7672
This patch started innocently enough, by deleting a single
call from rnImportDecl, namely
let gbl_env = mkGlobalRdrEnv (filterOut from_this_mod gres)
The 'filterOut' makes no sense, and was the cause of #7672.
But that little loose end led to into a twisty maze of little
passages, all alike, which has taken me an unreasonably long
time to straighten out. Happily, I think the result is really
much better.
In particular:
* INVARIANT 1 of the GlobalRdrEnv type was simply not true:
we had multiple GlobalRdrElts in a list with the same
gre_name field. This kludgily implmented one form of
shadowing.
* Meanwhile, extendGlobalRdrEnvRn implemented a second form of
shadowing, by deleting stuff from the GlobalRdrEnv.
* In turn, much of this shadowing stuff depended on the Names of
the Ids bound in the GHCi InteractiveContext being Internal
names, even though the TyCons and suchlike all had External
Names. Very confusing.
So I have made the following changes
* I re-established INVARIANT 1 of GlobalRdrEnv. As a result
some strange code in RdrName.pickGREs goes away.
* RnNames.extendGlobalRdrEnvRn now makes one call to deal with
shadowing, where necessary, and another to extend the
environment. It deals separately with duplicate bindings.
The very complicated RdrName.extendGlobalRdrEnv becomes much
simpler; we need to export the shadowing function, now called
RdrName.shadowNames; and we can nuke
RdrName.findLocalDupsRdrEnv altogether.
RdrName Note [GlobalRdrEnv shadowing] summarises the shadowing
story
* The Names of the Ids bound in the GHCi interactive context are
now all External. See Note [Interactively-bound Ids in GHCi]
in HscTypes.
* Names for Ids created by the debugger are now made by
IfaceEnv.newInteractiveBinder. This fixes a lurking bug which
was that the debugger was using mkNewUniqueSupply 'I' to make
uniques, which does NOT guarantee a fresh supply of uniques on
successive calls.
* Note [Template Haskell ambiguity] in RnEnv shows that one TH-related
error is reported lazily (on occurrences) when it might be better
reported when extending the environment. In some (but not all) cases
this was done before; but now it's uniformly at occurrences. In
some ways it'd be better to report when extending the environment,
but it's a tiresome test and the error is rare, so I'm leaving it
at the lookup site for now, with the above Note.
* A small thing: RnNames.greAvail becomes RdrName.availFromGRE, where
it joins the dual RdrName.gresFromAvail.
}}}
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7672#comment:15>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#10473: Haskell Platform generic linux installer creates incorrect symlinks for
/usr/local/man/man1 (and probably /usr/local/share/doc) when directory does
not already exist
-------------------------------------+-------------------------------------
Reporter: brson | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.10.1
Keywords: | Operating System: Linux
Architecture: | Type of failure: None/Unknown
Unknown/Multiple | Blocked By:
Test Case: | Related Tickets:
Blocking: |
Differential Revisions: |
-------------------------------------+-------------------------------------
Following instructions here https://www.haskell.org/platform/linux.html
for 'generic linux binaries'. After running activate-hs my
/usr/local/man/man1 was a symlink to ghc.1 when it should be a directory
*containing* ghc.1. This happens when the directory /usr/local/man/man1
does not already exist.
Running activate-hs with --verbose --dryrun shows why:
ln -sf usr/local/haskell/ghc-7.8.3-x86_64/bin/HsColour
usr/local/haskell/ghc-7.8.3-x86_64/bin/activate-hs
usr/local/haskell/ghc-7.8.3-x86_64/bin/alex
usr/local/haskell/ghc-7.8.3-x86_64/bin/cabal usr/local/hask
ell/ghc-7.8.3-x86_64/bin/ghc
usr/local/haskell/ghc-7.8.3-x86_64/bin/ghc-7.8.3
usr/local/haskell/ghc-7.8.3-x86_64/bin/ghc-pkg
usr/local/haskell/ghc-7.8.3-x86_64/bin/ghc-pkg-7.8.3
usr/local/haskell/ghc-7.8.3-x86_64/
bin/ghci usr/local/haskell/ghc-7.8.3-x86_64/bin/ghci-7.8.3
usr/local/haskell/ghc-7.8.3-x86_64/bin/haddock
usr/local/haskell/ghc-7.8.3-x86_64/bin/haddock-ghc-7.8.3
usr/local/haskell/ghc-7.8.3-x86_64/bin/happy usr/l
ocal/haskell/ghc-7.8.3-x86_64/bin/hp2ps
usr/local/haskell/ghc-7.8.3-x86_64/bin/hpc
usr/local/haskell/ghc-7.8.3-x86_64/bin/hsc2hs
usr/local/haskell/ghc-7.8.3-x86_64/bin/runghc
usr/local/haskell/ghc-7.8.3-x86_64/bin
/runghc-7.8.3 usr/local/haskell/ghc-7.8.3-x86_64/bin/runhaskell
/usr/local/bin
ln -sf usr/local/haskell/ghc-7.8.3-x86_64/share/man/man1/ghc.1
/usr/local/share/man/man1
ln -sf usr/local/haskell/ghc-7.8.3-x86_64/share/doc/ghc
/usr/local/share/doc
usr/local/haskell/ghc-7.8.3-x86_64/bin/ghc-pkg register --verbose=0
--force
usr/local/haskell/ghc-7.8.3-x86_64/etc/registrations/GLURaw-1.4.0.1
usr/local/haskell/ghc-7.8.3-x86_64/bin/ghc-pkg register --verbose=0
--force usr/local/haskell/ghc-7.8.3-x86_64/etc/registrations/GLUT-2.5.1.1
The second and third ln commands are incorrect. When there are multiple
sources it treats the dest as a directory, but in these two instances
there are only a single source so ln just creates man1 as a symlink.
FWIW when this happens a subsequent install of Rust fails:
https://github.com/rust-lang/rust-installer/issues/36. Rust v. Haskell:
fight!
```
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10473>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#10471: Confusing parse error when forgetting "deriving"
-------------------------------------+-------------------------------------
Reporter: | Owner:
AlexanderThiemann | Status: new
Type: bug | Milestone:
Priority: normal | Version: 7.6.3
Component: Compiler | Operating System: Unknown/Multiple
Keywords: | Type of failure: Incorrect
Architecture: | warning at compile-time
Unknown/Multiple | Blocked By:
Test Case: | Related Tickets:
Blocking: |
Differential Revisions: |
-------------------------------------+-------------------------------------
This code:
{{{
module Main where
data Foo
= Foo
{ f_x :: Int
, f_y :: Int
} (Eq, Show)
}}}
Produces this error message:
{{{
foo.hs:5:7: Not in scope: `f_x'
foo.hs:6:7: Not in scope: `f_y'
}}}
I'm not sure how easy it is to improve the error message; but a "Not in
scope" seems very confusing to me...
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10471>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7672: boot file entities are sometimes invisible and are not (semantically)
unified with corresponding entities in implementing module
-------------------------------------+-------------------------------------
Reporter: skilpat | Owner: ezyang
Type: bug | Status: new
Priority: normal | Milestone: 7.12.1
Component: Compiler (Type | Version: 7.4.2
checker) | Keywords: backpack
Resolution: | Architecture: x86_64
Operating System: Linux | (amd64)
Type of failure: GHC rejects | Test Case: T7672
valid program | Blocking: 10336
Blocked By: | Differential Revisions:
Related Tickets: |
-------------------------------------+-------------------------------------
Comment (by simonpj):
Edward: I have a fix for this in-flight.
Simon
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7672#comment:14>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7170: Foreign.Concurrent finalizer called twice in some cases
-------------------------------------+-------------------------------------
Reporter: joeyadams | Owner: niteria
Type: bug | Status: patch
Priority: high | Milestone: 7.6.1
Component: Core Libraries | Version: 7.8.3
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: Runtime crash | Unknown/Multiple
Blocked By: | Test Case:
Related Tickets: | ffi/should_run/7170
| Blocking:
| Differential Revisions: D921
-------------------------------------+-------------------------------------
Comment (by Simon Marlow <marlowsd@…>):
In [changeset:"dfdc50d666498c5a1118557d67209fe067c61cc1/ghc"]:
{{{
#!CommitTicketReference repository="ghc"
revision="dfdc50d666498c5a1118557d67209fe067c61cc1"
Don't call DEAD_WEAK finalizer again on shutdown (#7170)
Summary:
There's a race condition like this:
# A foreign pointer gets promoted to the last generation
# It has its finalizer called manually
# We start shutting down the runtime in `hs_exit_` from the main
thread
# A minor GC starts running (`scheduleDoGC`) on one of the threads
# The minor GC notices that we're in `SCHED_INTERRUPTING` state and
advances to `SCHED_SHUTTING_DOWN`
# The main thread tries to do major GC (with `scheduleDoGC`), but it
exits early because we're in `SCHED_SHUTTING_DOWN` state
# We end up with a `DEAD_WEAK` left on the list of weak pointers of
the last generation, because it relied on major GC removing it from
that list
This change:
* Ignores DEAD_WEAK finalizers when shutting down
* Makes the major GC on shutdown more likely
* Fixes a bogus assert
Test Plan:
before this diff https://ghc.haskell.org/trac/ghc/ticket/7170#comment:5
reproduced and after it doesn't
Reviewers: ezyang, austin, simonmar
Reviewed By: simonmar
Subscribers: bgamari, thomie
Differential Revision: https://phabricator.haskell.org/D921
GHC Trac Issues: #7170
}}}
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7170#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
