February 2016 - ghc-tickets

[GHC] #11657: Varpes.L!plock trojan shipped in HaskellPlatform-7.10.3-i386-setup.exe?
by GHC 28 Feb '16

28 Feb '16

#11657: Varpes.L!plock trojan shipped in HaskellPlatform-7.10.3-i386-setup.exe? --------------------------------------------+---------------------------- Reporter: swithers | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.10.3 Keywords: Virus Trojan Malware | Operating System: Windows Architecture: x86 | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------------+---------------------------- Windows defender scan of HaskellPlatform-7.10.3-i386-setup.exe detected severe malware. Varpes.L!plock trojan "This program is dangerous and executes commands from an attacker" -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11657> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #7388: CAPI doesn't work with ghci
by GHC 28 Feb '16

28 Feb '16

#7388: CAPI doesn't work with ghci -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T4012 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Can someone clarify what "CAPI" means in this context? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7388#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7388: CAPI doesn't work with ghci
by GHC 28 Feb '16

28 Feb '16

#7388: CAPI doesn't work with ghci -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T4012 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jystic): * cc: jystic@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7388#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9043: Add missing type class instances for data types in GHC.Generics
by GHC 27 Feb '16

27 Feb '16

#9043: Add missing type class instances for data types in GHC.Generics ------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- GHC.Generics offers a bunch of data types which have valid instances of various type classes in base, such as Functor. There's no good reason not to have these instances, so they should be added. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9043> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 38

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 27 Feb '16

27 Feb '16

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Changes (by niteria): * wikipage: => DeterministicBuilds -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:143> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10316: Move Typeable type-rep generation from use site to definition site
by GHC 27 Feb '16

27 Feb '16

#10316: Move Typeable type-rep generation from use site to definition site -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This ticket is a continuation of #9858. The interim solution for 7.10 was to generate `Typeable` data structures on the fly, as needed in client modules. This ticket is about moving the generation of the runtime representation of type constructors to their definition sites. (#9858 already has too much going on in it, so I started a fresh ticket for this refactoring.) The branch is `wip/T9858-typeable-spj`. In favour of (A) code at use site (as in 7.10): * Pay as you go. No code at all is generated unless you use `Typeable` In favour of (B) code at definition site: * More sharing. We make a `TyCon` (see `Data.Typeable.Internal`) for `T` (say) just once, in the module that defines `T`. * We may ultimately want the `TyCon` for `T` to include its source location, and perhaps more besides. If it is defined in `T` it becomes easier to do that. General observation: (B) is like `Typeable` was before, when it was an ordinary class. The difference now is that all types are `Typeable`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10316> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11633: Record field order in a bidirectional pattern synonym match is order dependent
by GHC 27 Feb '16

27 Feb '16

#11633: Record field order in a bidirectional pattern synonym match is order dependent -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.3 (Type checker) | Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this example, {{{#!hs {-# LANGUAGE PatternSynonyms #-} module Test where data ARecord = ARecord {anInt :: Int, aString :: String} -- This works... pattern AGoodPat :: Int -> String -> ARecord pattern AGoodPat n s = ARecord {anInt=n, aString=s} -- But if we invert the order of the fields things break... pattern ABadPat :: Int -> String -> ARecord pattern ABadPat n s = ARecord {aString=s, anInt=n} }}} Despite the fact that `AGoodPat` and `ABadPat` differ only in the order of the fields in their matches, `ABadPat` fails to typecheck with, {{{ Test.hs:12:40: error: • Couldn't match type ‘[Char]’ with ‘Int’ Expected type: Int Actual type: String • In the first argument of ‘ARecord’, namely ‘s’ In the expression: ARecord s n In an equation for ‘$bABadPat’: $bABadPat n s = ARecord s n Test.hs:12:49: error: • Couldn't match type ‘Int’ with ‘[Char]’ Expected type: String Actual type: Int • In the second argument of ‘ARecord’, namely ‘n’ In the expression: ARecord s n In an equation for ‘$bABadPat’: $bABadPat n s = ARecord s n }}} This can be observed with both 7.10.3 and `master`. If one makes `ABadPat` into a one-directional pattern then the error vanishes. The fact that field order matters in the case of bi-directional record pattern synonyms seems a bit odd. If there's a good reason why this must be the case then fair enough, but we should make sure this is mentioned in the users guide and provide a more helpful error message. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11633> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11579: Bug in parser for named Haddock chunks since GHC 8.0.1-rc1
by GHC 27 Feb '16

27 Feb '16

#11579: Bug in parser for named Haddock chunks since GHC 8.0.1-rc1 -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Steps to reproduce: {{{ -- Foo.hs module Foo where -- $bar some -- named chunk }}} {{{ -- Extract.hs module Extract where import Prelude hiding (mod) import Data.Generics import DynFlags import FastString import GHC import GHC.Paths extractDocStrings :: IO [String] extractDocStrings = do extract . pm_parsed_source <$> do runGhc (Just libdir) $ do _ <- getSessionDynFlags >>= setSessionDynFlags . setHaddockMode guessTarget "Foo.hs" Nothing >>= setTargets . return [mod] <- depanal [] False parseModule mod where setHaddockMode :: DynFlags -> DynFlags setHaddockMode dynflags = (gopt_set dynflags Opt_Haddock) extract :: ParsedSource -> [String] extract m = [unpackFS s | HsDocString s <- everything (++) ([] `mkQ` return) m] }}} Expected result: {{{extractDocStrings}}} returns {{{" some\n named chunk"}}} Actual result: it returns {{{" some"}}} instead -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11579> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11583: Make warning names more consistent
by GHC 27 Feb '16

27 Feb '16

#11583: Make warning names more consistent -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Sven Panne points out that current warning naming conventions used in GHC are rather inconsistent. Since we are moving away from `-fwarn-` to `-W` it would be nice if we could also try to fix up the names themselves. We do, however, want to make sure that transition isn't more painful for users than necessary. For instance, the user should be able to get useful feedback from the compiler on what warning flags have changed with `s/-fwarn-/-W/` To this end I recommend the following, * We write down a consistent vocabulary for warning flag names * We keep `-fwarn-` flags as they are currently * We keep the inconsistently named -W flags corresponding to these `-fwarn-` flags * We add consistently named `-W` flags alongside these * We set a timeline for deprecating the inconsistent forms (perhaps in three or four releases) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11583> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939
by GHC 27 Feb '16

27 Feb '16

#11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This happens when trying to update the `transformers` submodule to 0.5.2.0 (see `wip/transformers-0.5.2`-branch), then during `validate` the following panic occurs: {{{ "inplace/bin/ghc-stage1" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -hide-all-packages -i -ighc/. -ighc/stage2/build -ighc/stage2/build/autogen -Ighc/stage2/build -Ighc/stage2/build/autogen -optP-DGHCI -optP-include -optPghc/stage2/build/autogen/cabal_macros.h -package-id array-0.5.1.0 -package-id base-4.9.0.0 -package-id bytestring-0.10.7.0 -package-id containers-0.5.7.1 -package-id deepseq-1.4.2.0 -package-id directory-1.2.5.1 -package-id filepath-1.4.1.0 -package-id ghc-8.1 -package-id ghc-boot-8.1 -package-id ghci-8.1 -package-id haskeline-0.7.2.2 -package-id process-1.4.2.0 -package-id time-1.6 -package-id transformers-0.5.2.0 -package-id unix-2.7.2.0 -Wall -fno-warn-name-shadowing -XHaskell2010 -O -dcore-lint -no-hs-main -threaded -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir ghc/stage2/build -hidir ghc/stage2/build -stubdir ghc/stage2/build -c ghc/./GHCi/UI.hs -o ghc/stage2/build/GHCi/UI.dyn_o WARNING: file compiler/specialise/Specialise.hs, line 1173 Missed specialisation opportunity for $fMonadIOExceptT_$cliftIO [] 2 [] 1 [ALWAYS] WARNING: file compiler/specialise/Specialise.hs, line 1173 Missed specialisation opportunity for $w$c<*> [] 2 [] 1 [0] ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.1.20160218 for x86_64-unknown-linux): ASSERT failed! file compiler/types/TyCoRep.hs line 1939 in_scope InScope {fromTarget_aiKD pprTT_aj4s pp_resume_aj4J opts_ajdx flagList_ajdy $dMonad_anX0 $dOrd_areH $dEq_as40 $dRead_as5N $dEq_aswW $dMonadIO_at39 $dApplicative_atce $dShow_atnW $dMonad_ats4 $dFunctor_atsk $dNFData_awOZ $dEq_azf8 $dFunctor_azfb $dHasGhciState_azfd $dNFData_aAFw $trModule availableCommands shortHelpText fullHelpText defPrompt defPrompt2 defaultGhciSettings ghciWelcomeMsg ghciCommands word_break_chars specials spaces flagWordBreakChars keepGoing keepGoing' keepGoingPaths defShortHelpText defFullHelpText findEditor default_progname default_prompt default_prompt2 interactiveUI resetLastErrorLocations withGhcAppData runGHCiInput checkFileAndDirPerms checkPerms incrementLineNo fileLoop mkPrompt queryQueue installInteractivePrint runCommands runCommands' runOneCommand checkInputForLayout enqueueCommands runStmt afterRunStmt runSuccess runAllocs printTypeOfNames compareNames printTypeOfName lookupCommand' getCurrentBreakSpan getCurrentBreakModule noArgs withSandboxOnly help info filterOutChildren pprInfo doWithArgs changeDirectory trySuccess chooseEditFile defineMacro getGhciStepIO deferredLoad loadModule loadModule_ reloadModule doLoadAndCollectInfo afterLoad setContextAfterLoad setContextKeepingPackageModules keepPackageImports runExceptGhcMonad exceptT parseSpanArg showSrcSpan showRealSrcSpan kindOfType isSafeModule browseCmd guessCurrentModule browseModule addModulesToContext addModulesToContext_ remModulesFromContext setContext addII restoreContextOnFailure checkAdd setGHCContextFromGHCiState mkIIDecl iiModules iiModuleName preludeModuleName implicitPreludeImport isPreludeImport iiSubsumes showOptions showDynFlags setArgs setProg setEditor setStop setPrompt setPrompt2 setPrompt_ packageFlagsChanged newDynFlags isMinus isPlus setOpt unsetOpt strToGHCiOpt showImports showModules getLoadedModules showBindings showBkptTable showContext pprStopped showPackages showPaths showLanguages showiLanguages showLanguages' ghciCompleteWord completeGhciCommand completeIdentifier completeModule listHomeModules completeSetOptions completeHomeModuleOrFile wrapCompleter wrapIdentCompleter completeExpression pprintCommand stepCmd leftmostLargestRealSrcSpan doContinue bold breakSwitch breakByModuleLine breakSyntax findBreakAndSet findBreakByCoord do_bold start_bold end_bold listModuleLine listAround getTickArray discardTickArrays discardActiveBreakPoints turnOffBreak getModBreak handler showException ghciHandle tryBool lookupModule lookupModuleName expandPath expandPathIO wantInterpretedModule wantInterpretedModuleName wantNameFromInterpretedModule $tc'GhciSettings $tcGhciSettings $tc'GotCommand $tc'BadCommand $tc'NoLastCommand $tcMaybeCommand a_sKa7 a_sKa8 a_sKa9 a_sKaa a_sKag a_sKah a_sKai a_sKaj a_sKdg a_sKrw a_sKvG a_sKvH a_sKvI a_sKwn a_sKwo a_sKws a_sKwt a_sKxU a_sKxV a_sKy8 a_sKy9 a_sKyg a_sKyh a_sKyk a_sKyl a_sKyV a_sKAe a_sKAk a_sKAl a_sKAm a_sKAn a_sKAo a_sKAp a_sKAq a_sKAr a_sKAs a_sKAt a_sKAu a_sKD4 a_sKEx a_sKEy a_sKEz a_sKEA a_sKEB a_sKEC a_sKF1 a_sKF2 a_sKFj a_sKFk a_sKFm a_sKFn a_sKMd a_sKMe a_sKMf a_sKMg a_sKMh a_sKOX a_sKQx a_sKQy a_sKTg a_sKWr a_sKWs a_sKWt a_sLrp a_sLrs a_sLrB a_sLs3 a_sLs5 a_sLsd a_sLsV a_sLtg a_sLtY a_sLv2 a_sLv7 a_sLvB a_sLvF a_sLvP a_sLvT a_sLwI} tenv [alhH :-> InputT GHCi, alhI :-> e_alhI] tenvFVs [alhI :-> e_alhI] cenv [] cenvFVs [] tys [] cos [forall (a17_aDzt :: <*>_N). <String>_R -> Sym (N:ExceptT[0] <e_alhI>_N <m_alhH>_R <a17_aDzt>_N)] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ghc/ghc.mk:112: recipe for target 'ghc/stage2/build/GHCi/UI.dyn_o' failed }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11600> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15