Re: Understanding how warnings on unused functions work

e way collects sets of defined/used names in tcg_dus. There are also a set of names used by the typechecker in tcg_keep. After typechecking, findUses takes the transitive closure of the set of uses and reportUnusedNames then issues unused-top-binds warnings for all names defined in the current m

Understanding how warnings on unused functions work

This message is related to a feature in the futhark compiler , which is a language with a similar module system. I am trying to create a tool to detect unused top-level functions in Futhark, and I have been looking in the ghc codebase to find out how

Re: Warnings in RTS

Simon Peyton Jones writes: > Whenever I compile the RTS I get these warnings. Are they necessary? > Indeed they aren't and I doubt that inlining of these is even beneficial. I have opened #22280 to track this. Cheers, - Ben signature.asc Description: PG

Warnings in RTS

Whenever I compile the RTS I get these warnings. Are they necessary? Simon In file included from rts/Schedule.c:16:0: error: rts/Schedule.c: In function ‘schedule’: rts/Schedule.h:143:1: error: warning: inlining failed in call to ‘appendToRunQueue’: call is unlikely and code size would

Re: Case split uncovered patterns in warnings or not?

mplete-patterns] >> Pattern match(es) are non-exhaustive >> In an equation for ‘foo’: >> Patterns not matched: >> False (integer-gmp-1.0.3.0:GHC.Integer.Type.S# _) >> False (integer-gmp-1.0.3.0:GHC.Integer.Type.Jp#

Re[2]: Case split uncovered patterns in warnings or not?

- Von: "Vladislav Zavialov" An: "Oleg Grenrus" Cc: "ghc-devs" Gesendet: 10.11.2021 10:51:03 Betreff: Re: Case split uncovered patterns in warnings or not? Integer is an interesting example. I think it reveals another issue: exhaustiveness checking should a

Re: Case split uncovered patterns in warnings or not?

eger-gmp-1.0.3.0:GHC.Integer.Type.Jp# _) > False (integer-gmp-1.0.3.0:GHC.Integer.Type.Jn# _) > | > 4 | foo True i = i > | ^^^ > > - Oleg > > > On 9.11.2021 15.17, Sebastian Graf wrote: >> Hi Devs, >> >> In https://gitlab.haskell.org/ghc

Re: Case split uncovered patterns in warnings or not?

Sebastian Graf wrote: > Hi Devs, > > In https://gitlab.haskell.org/ghc/ghc/-/issues/20642 > <https://gitlab.haskell.org/ghc/ghc/-/issues/20642> we saw that GHC >= > 8.10 outputs pattern match warnings a little differently than it used > to. Example from there: > >

Re: Re[2]: Case split uncovered patterns in warnings or not?

ore general and > less ad-hoc than the behavior of 8.8. Maybe there isn't and 8.8 already > lived in the sweet spot. > > -- Originalnachricht -- > Von: "Richard Eisenberg" > An: "Sebastian Graf" > Cc: "ghc-devs" > Gesendet: 10.11.2

Re[2]: Case split uncovered patterns in warnings or not?

Originalnachricht -- Von: "Richard Eisenberg" An: "Sebastian Graf" Cc: "ghc-devs" Gesendet: 10.11.2021 04:44:50 Betreff: Re: Case split uncovered patterns in warnings or not? Maybe the answer should depend on whether the scrutinee has already been forced. The

Re: Case split uncovered patterns in warnings or not?

; we saw that GHC >= 8.10 > outputs pattern match warnings a little differently than it used to. Example > from there: > > {-# OPTIONS_GHC -Wincomplete-uni-patterns #-} > > foo :: [a] -> [a] > foo [] = [] > foo xs = ys > where > (_, ys@(_:_)) = sp

Case split uncovered patterns in warnings or not?

Hi Devs, In https://gitlab.haskell.org/ghc/ghc/-/issues/20642 we saw that GHC >= 8.10 outputs pattern match warnings a little differently than it used to. Example from there: {-# OPTIONS_GHC -Wincomplete-uni-patterns #-}foo :: [a] -> [a]foo [] = []foo xs = ys where (_, ys@(_:_)) = spl

Re: Warnings

Simon Peyton Jones via ghc-devs writes: > If 'transformers' purposely has orphan instances, shouldn't we switch off the > warnings about them? > Simon > We actually do so in Make, but strangely only in the stage2 build (see mk/warnings.mk). It's unclear to me w

Warnings

If 'transformers' purposely has orphan instances, shouldn't we switch off the warnings about them? Simon "/opt/ghc/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -package-db libraries/bootstrapping.conf -this-unit-id transformers-0.5.6.2 -hide-all-p

Re: Implementation of Type level warnings

I've responded on the MR. Thanks for stepping up to do this! Richard > On Dec 30, 2019, at 5:53 AM, Rowan Goemans wrote: > > Hello everyone, > > A couple of days ago I tried to implement type level warnings [1]. I have got > something > now that sort of works b

Implementation of Type level warnings

Hello everyone, A couple of days ago I tried to implement type level warnings [1]. I have got something now that sort of works but issues the same warning multiple times and not on the correct location. It's currently a WIP merge request [2]. I would like some help/pointers to continu

Re: Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms

false incomplete pattern matching warnings in GHC? Should we add clauses like `foo _ = panic "Impossible! How did you manage to bypass a complete matching?"`? /Shayan On Mon, 29 Oct 2018 at 14:52, Sylvain Henry wrote: > > I've just found this related ticket: > https://

Re: Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms

I've just found this related ticket: https://ghc.haskell.org/trac/ghc/ticket/14422 On 10/26/18 7:04 PM, Richard Eisenberg wrote: Aha. So you're viewing complete sets as a type-directed property, where we can take a type and look up what complete sets of patterns of that type might be. Then,

Re: Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms

> On Oct 26, 2018, at 9:43 PM, Carter Schonwald > wrote: > > ORDER of the abstracted constructors matters! That's a very good point. So we don't have a set of sets -- we have a set of lists (where normal constructors -- which have no overlap -- would appear in the lists in every possible pe

Re: Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms

off hand, once we're in in viewpattern/ pattern synonym land, ORDER of the abstracted constructors matters! consider foo,bar,baz,quux,boom :: Nat -> String plus some pattern synonyms i name "PowerOfTwo", "Even" and "Odd" foo (PowerOfTwo x) = "power of two" foo (Even x) = "even" foo (Odd x) = "od

Re: Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms

Aha. So you're viewing complete sets as a type-directed property, where we can take a type and look up what complete sets of patterns of that type might be. Then, when checking a pattern-match for completeness, we use the inferred type of the pattern, access its complete sets, and if these match

Re: Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms

Sorry I wasn't clear. I'm not an expert on the topic but it seems to me that there are two orthogonal concerns: 1) How does the checker retrieve COMPLETE sets. Currently it seems to "attach" them to data type constructors (e.g. Maybe). If instead it retrieved them by matching types (e.g. "Mayb

Re: Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms

I'm afraid I don't understand what your new syntax means. And, while I know it doesn't work today, what's wrong (in theory) with {-# COMPLETE LL #-} No types! (That's a rare thing for me to extol...) I feel I must be missing something here. Thanks, Richard > On Oct 25, 2018, at 12:24 PM, Sylv

Re: Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms

In the case where all the patterns are polymorphic, a user must provide a type signature but we accept the definition regardless of the type signature they provide. Currently we can specify the type *constructor* in a COMPLETE pragma: pattern J :: a -> Maybe apattern J a = Just apattern N :: M

Re: Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms

t; Pat unLocPat (LL _ m) = m unLocGen :: HasLoc a => a -> SrcSpanLess a unLocGen (LL _ m) = m }}} In the functions `unLocExp` and `unLocPat`, the related COMPLETE pragmas rightly avoid the false incomplete pattern matching warnings. However, to avoid the false incomplete pattern matching warn

Re: Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms

You *can* put `LL` into a COMPLETE set, but under the stipulation that you specify which type constructor it's monomorphized to. To quote the wiki page on COMPLETE sets: In the case where all the patterns are polymorphic, a user must provide a type signature but we accept the definition regard

Re: Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms

I think that `LL` is precisely intended for abstraction. If this `COMPLETE` pragma were possible to implement then a user shouldn't know the difference between the old and new representations. The reason that `COMPLETE` pragmas are designed like this is that it's how the pattern match checker is d

Re: Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms

In a rare move, I disagree with Ryan here. Why don't we want LL to be abstract? I personally don't want to be thinking of some desugaring to a view pattern when I say LL. I want just to be pattern matching. Is there a reason we can't extend COMPLETE pragmas to cover this case? Richard > On Oct

Re: Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms

The fact that `LL` can't be used in a COMPLETE pragma is a consequence of its current design. Per the users' guide [1]: To make things more formal, when the pattern-match checker requests a set of constructors for some data type constructor T, the checker returns: * The original set of da

Re: Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms

ch a polymorphic pattern. > > What do you suggest us to do to avoid the false incomplete pattern > matching warnings? > > Thanks, > Shayan > > [0] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow > [1] > https://ghc.haskell.org/trac/ghc/wiki/Implementing

Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms

annot be used with such a polymorphic pattern. What do you suggest us to do to avoid the false incomplete pattern matching warnings? Thanks, Shayan [0] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow [1] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/TreesThatGrowG

Redundant import warnings

| those 143, I noticed new warnings being emitted in 31 of them (~22%): | | {{{ | - adjunctions-4.4 | - aeson-1.4.0.0 | - ansi-wl-pprint-0.6.8.2 | - asn1-encoding-0.9.5 | - async-2.2.1 | - attoparsec-0.13.2.2 | - blaze-builder-0.4.1.0 | - cassava-0.5.1.0 | - conduit-1.3.0.3 | - cookie

Re: Strictness/laziness warnings

This is strictness over sum types. Ömer and I worked on adding it to a fork of GHC. It's definitely possible, the main complications are how to deal with recursive types in the presence of polymorphic recursion and how to detect recursive types in the presence of higher-kinded types. Because the f

Re: Strictness/laziness warnings

Mostly I'm looking for a rough estimate. Some false positives and false negatives are tolerable. If I have something like f :: Int -> Maybe String -> String f _ Nothing = "Hi there!" f n (Just b) = if n > 0 then show b else "whatever" then I'd likely be interested in a warning about the fact that

Re: Strictness/laziness warnings

How would you detect the argument only being forced some of the time? Sounds like a lot of long-term cross-module book-keeping. -Edward On Sat, May 28, 2016 at 10:02 PM, David Feuer wrote: > I'm not suggesting these things are *wrong*, and I wouldn't want the > warnings to be i

Re: Strictness/laziness warnings

I'm not suggesting these things are *wrong*, and I wouldn't want the warnings to be included in -Wall. They're just possible areas of concern. By "conditionally strict" I mean that the argument in question is only forced sometimes. On May 28, 2016 9:16 PM, "Edward

Re: Strictness/laziness warnings

nd what you mean by "conditionally strict" in an argument though. -Edward On Sat, May 28, 2016 at 8:00 PM, David Feuer wrote: > There are certain patterns of strictness or laziness that signal the need > for extra caution. I'm wondering whether it might be possible to offer > wa

Strictness/laziness warnings

There are certain patterns of strictness or laziness that signal the need for extra caution. I'm wondering whether it might be possible to offer warnings for different varieties of them, and pragmas suppressing the warnings at the relevant sites. Some function behaviors that suggest extra car

Lint warnings

Lint has started emitting lots of warnings like this, when compiling libraries. Lint warning: case binder's type has no constructors ds_sPA5 V1 p_a7vb Does anyone have any idea why? Simon ___ ghc-devs mailing list ghc-devs@haskell.org

RE: Warnings, -Wall, and versioning policy

users ; ghc-devs@haskell.org; | Edward Kmett ; Herbert Valerio Riedel ; Simon | Marlow | Subject: Re: Warnings, -Wall, and versioning policy | | On Wed, Jan 13, 2016 at 7:43 AM, Simon Peyton Jones | wrote: | | > An implication is that GHC is free to introduce new warnings X into -Wall. | Ind

Re: Warnings, -Wall, and versioning policy

On Wed, Jan 13, 2016 at 7:43 AM, Simon Peyton Jones wrote: > An implication is that GHC is free to introduce new warnings X into -Wall. > Indeed doing so would be good, because the warning X might later move into > the default set. Indeed for such warnings, adding a "PS: thi

RE: Warnings, -Wall, and versioning policy

Thanks Gershom. That all sounds fine to me. An implication is that GHC is free to introduce new warnings X into -Wall. Indeed doing so would be good, because the warning X might later move into the default set. Indeed for such warnings, adding a "PS: this warning will become the de

Re: Warnings, -Wall, and versioning policy

_default_ set without at least a few releases in some other set such as `-Wall`. We may also want to try to maintain a “best practices” example cabal file that shows how one can build with additional warnings under a “dev” flag, and with fewer warnings otherwise — so that the noise inflicted on package

Warnings, -Wall, and versioning policy

tly. Here it is: We guarantee that code that compiles with no warnings with -Wall ("Wall-clean") and a particular GHC version, on a particular platform, will be Wall-clean with future minor releases of the same major GHC version on the same platform. (we plan to put this text in

Re: Flag warnings show intermediate hscpp filenames on SmartOS

Configuring GHC with modified hs-cpp-flags works to fix the tests: ./configure --with-hs-cpp-flags="-specs=/opt/local/etc/ghc/overridecpp.spec -E -undef -traditional -x assembler-with-cpp" overridecpp.spec: *cpp: %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT} The challenge now is

Re: Flag warnings show intermediate hscpp filenames on SmartOS

cpphs doesn't currently work for compiling GHC. libraries/base/GHC/Natural.hs uses a macro with arguments inside an if defined preprocessor expression and cpphs tries to expand the macro and errors since there are no arguments provided. This is non-compliant if cpphs is trying to be a C99 preproc

Re: Flag warnings show intermediate hscpp filenames on SmartOS

Progress Update: 1. fixing CPP fixes the majority of the remaining test failures 2. cpphs builds and runs successfully on SmartOS 3. --with-hs-cpp-flags='-specs=overridecpp.spec" can be used in lieu of a wrapper script 3. I am running some experiments with cpphs to see how it works 4. I will run so

Re: Flag warnings show intermediate hscpp filenames on SmartOS

Okay Karel. I have a solution that works to make T2464 pass. Create overridecpp.spec: *cpp: %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT} Create ghc-cpp and make it executable: #!/bin/bash gcc -spec=/path/to/overridecpp.spec $@ Configure and make GHC with ghc-cpp and run T2464: ./configur

Re: Flag warnings show intermediate hscpp filenames on SmartOS

Actually Karel, if "gcc -dumpspecs" shows you that same -P as I get you can override it with spec files as described here: https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html I think this means that you could specify "gcc -specs=/path/to/overridecpp.spec" as --with-hs-cpp when building GHC. I'm tr

Re: Flag warnings show intermediate hscpp filenames on SmartOS

True, but I'd still like to find a mutual solution since we're both somewhat at the edge of the supported landscape for GHC. Is installing cpphs and configuring GHC to use that an option on Solaris 11? I haven't built cpphs successfully on SmartOS yet. Supplying a custom C preprocessor may be your

Re: Flag warnings show intermediate hscpp filenames on SmartOS

Alain, indeed, on SmartOS you are free to modify the supplied GCC so the fix to remove -P is most natural one. On the other hand I'm not so lucky with binary Solaris 11.x distribution provided by Oracle so I need to use not so clean and nice workarounds... Karel On 01/ 1/16 12:17 AM, Alain

Re: Flag warnings show intermediate hscpp filenames on SmartOS

cpphs isn't a direct option. It won't install on SmartOS with Cabal. GCC 4.7 is the earliest GCC supported so I'll have to try something else for SmartOS. It looks like the GCC Specs are the problem. On Ubuntu the Spec for cpp is: *cpp: %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT} On Smar

Re: Flag warnings show intermediate hscpp filenames on SmartOS

Thanks for the clarification. I understand now. On Thu, Dec 31, 2015 at 16:52 Karel Gardas wrote: > On 12/31/15 07:41 PM, Alain O'Dea wrote: > > Yes. I can do that. > > > > On SmartOS it may not be GCC 3.4.3 causing this. I see this on GCC 4.7.x > > through 4.9.x. The paths to gcc on SmartOS also

Re: Flag warnings show intermediate hscpp filenames on SmartOS

On 12/31/15 07:41 PM, Alain O'Dea wrote: Yes. I can do that. On SmartOS it may not be GCC 3.4.3 causing this. I see this on GCC 4.7.x through 4.9.x. The paths to gcc on SmartOS also differ. I'll have to verify that as part of checking this. This is misunderstanding. GCC 3.4.3 provides *correct

Re: Flag warnings show intermediate hscpp filenames on SmartOS

Yes. I can do that. On SmartOS it may not be GCC 3.4.3 causing this. I see this on GCC 4.7.x through 4.9.x. The paths to gcc on SmartOS also differ. I'll have to verify that as part of checking this. I think requiring cpphs on Illumos and Solaris might be a reasonable compromise. I like the idea

Re: Flag warnings show intermediate hscpp filenames on SmartOS

On 12/31/15 01:30 PM, Ben Gamari wrote: Karel Gardas writes: Hi Alain, I guess you are hit by well known issue in GCC's CPP on Solaris. Just verify here: https://gcc.gnu.org/ml/gcc/2014-08/msg00114.html solution in this case is simple: use configure option to set different non buggy CPP as

Re: Flag warnings show intermediate hscpp filenames on SmartOS

Thank you Karel. I'll try that tomorrow and report back my results. On Thu, Dec 31, 2015 at 09:00 Ben Gamari wrote: > Karel Gardas writes: > > > Hi Alain, > > > > I guess you are hit by well known issue in GCC's CPP on Solaris. Just > > verify here: > > > > https://gcc.gnu.org/ml/gcc/2014-08/ms

Re: Flag warnings show intermediate hscpp filenames on SmartOS

Karel Gardas writes: > Hi Alain, > > I guess you are hit by well known issue in GCC's CPP on Solaris. Just > verify here: > > https://gcc.gnu.org/ml/gcc/2014-08/msg00114.html > > solution in this case is simple: use configure option to set different > non buggy CPP as a CPP for GHC. > > Please

Re: Flag warnings show intermediate hscpp filenames on SmartOS

ifferent non buggy CPP as a CPP for GHC. Please let me know if this is the culprit, Thanks, Karel On 12/31/15 08:09 AM, Alain O'Dea wrote: On SmartOS GHC flag warnings show up like this: /tmp/ghc72341_0/ghc_1.hscpp:7:16: Warning: -fffi is deprecated: use -XForeignFunctionIn

Re: Flag warnings show intermediate hscpp filenames on SmartOS

lprit, Thanks, Karel On 12/31/15 08:09 AM, Alain O'Dea wrote: On SmartOS GHC flag warnings show up like this: /tmp/ghc72341_0/ghc_1.hscpp:7:16: Warning: -fffi is deprecated: use -XForeignFunctionInterface or pragma {-# LANGUAGE ForeignFunctionInterface #-} instead It appears that th

Flag warnings show intermediate hscpp filenames on SmartOS

On SmartOS GHC flag warnings show up like this: /tmp/ghc72341_0/ghc_1.hscpp:7:16: Warning: -fffi is deprecated: use -XForeignFunctionInterface or pragma {-# LANGUAGE ForeignFunctionInterface #-} instead It appears that this line in DriverPipeline leads to the correct filename in warnings on

Re: warnings in stage1

For what it's worth, I would get behind a movement to allow warnings in stage1, as long as we keep stage2 warning-free. That is, I could forgo my -Werror during stage1 if we felt that it's just better that way. Richard On Dec 4, 2015, at 4:44 PM, Richard Eisenberg wrote: > Hi d

warnings in stage1

Hi devs, I'm getting pattern-match warnings in my stage1 compiler. I assume that this is due to enhanced pattern-match checking. This is good! But I like to build (even stage1) with -Werror. Is this expected? Is someone working on this? Thanks! Ri

Re: Doc warnings

Simon Peyton Jones writes: > I'm getting these warnings relating to the user manual. They seem non-fatal, > but are alarming. > Simon > > > reading sources... [ 66%] ghc > > > > looking for now-outdated files... none found > > pickling environment... d

Doc warnings

I'm getting these warnings relating to the user manual. They seem non-fatal, but are alarming. Simon reading sources... [ 66%] ghc looking for now-outdated files... none found pickling environment... done checking consistency... /5playpen/simonpj/HEAD-2/docs/users_guide/ghc.rst:: WA

RE: warnings

OK would someone like to add the same warning-suppression to ghc.mk as I did for bytestring? Simon From: Thomas Miedema [mailto:thomasmied...@gmail.com] Sent: 28 July 2015 18:54 To: Simon Peyton Jones Cc: ghc-devs Subject: Re: warnings It is still failing, but now on the parallel and stm

Re: warnings

8, 2015 at 6:47 PM, Simon Peyton Jones wrote: > Hopefully done now. Sorry about this -- really busy day > > S > > > > *From:* Simon Peyton Jones > *Sent:* 28 July 2015 11:01 > *To:* 'ghc-devs' > *Subject:* RE: warnings > > > > Validating now, b

RE: warnings

Hopefully done now. Sorry about this -- really busy day S From: Simon Peyton Jones Sent: 28 July 2015 11:01 To: 'ghc-devs' Subject: RE: warnings Validating now, but have to go to London for a few hrs. Meanwhile use -Wwarn! From: Simon Peyton Jones Sent: 27 July 2015 17:08 To

RE: warnings

Validating now, but have to go to London for a few hrs. Meanwhile use -Wwarn! From: Simon Peyton Jones Sent: 27 July 2015 17:08 To: ghc-devs Subject: warnings Yurgh. I committed a patch but my validate had -Wwarn by mistake. So there are warnings in base (and binary actually). I will sort

warnings

Yurgh. I committed a patch but my validate had -Wwarn by mistake. So there are warnings in base (and binary actually). I will sort them out tomorrow. Could revert and re-apply but doesn't seem worth it. Sorry Simon ___ ghc-devs mailing list ghc

Re: clang warnings with unregisterised

On Fri, 29 Aug 2014 02:56:01 +0200 Gabor Greif wrote: > Devs, > > I have built an UNREGISTERISED GHC, and the C-compiler used behind the > scenes is clang. Now I get literally millions of warnings of the below > kind: > > > +/var/folders/k9/fj_1d5h17m7c4gbyp2s

clang warnings with unregisterised

Devs, I have built an UNREGISTERISED GHC, and the C-compiler used behind the scenes is clang. Now I get literally millions of warnings of the below kind: +/var/folders/k9/fj_1d5h17m7c4gbyp2srqrhmgq/T/ghc11601_0/ghc11601_4.hc:688:1: + warning: attribute declaration must precede

Core Lint warnings

Hello all, I see *literally thousands* of these warnings (in yesterday's and) today's bootstraps: {{{ HC [stage 1] libraries/base/dist-install/build/GHC/Base.o *** Core Lint warnings : in result of Desugar (after optimization) *** {-# LINE 261 "libraries/base/GHC/Base.l

Re: clang warnings

I ran a validate myself on OS X this evening, i can confirm things worked too :) On Mon, Jun 23, 2014 at 8:55 PM, Kazu Yamamoto wrote: > Austin, > > > I've already merged two changesets into 7.8.3 - > > > https://github.com/ghc/ghc/commit/5f9e0bedc9b08b46619f8ed4d09f645d6ed4 > > and > https

Re: clang warnings

Austin, > I've already merged two changesets into 7.8.3 - > https://github.com/ghc/ghc/commit/5f9e0bedc9b08b46619f8ed4d09f645d6ed4 > and https://github.com/ghc/ghc/commit/fd4169f9caf6922e3e5ea9c31f497f7220fc62b8 > - which add -Qunused-arguments to the C compiler invocation if the > compiler is

Re: clang warnings

Hi Mark, I've already merged two changesets into 7.8.3 - https://github.com/ghc/ghc/commit/5f9e0bedc9b08b46619f8ed4d09f645d6ed4 and https://github.com/ghc/ghc/commit/fd4169f9caf6922e3e5ea9c31f497f7220fc62b8 - which add -Qunused-arguments to the C compiler invocation if the compiler is Clang. T

Re: clang warnings

I'm the source of ghc-clang-wrapper. I can add "-Qunused-arguments" easily enough. I just last night ran across the spaces problem - and I'm not entirely sure the bug is in ghc-clang-wrapper! I'll investigate... turns out all you need to do is try to compile something that is in a directory with s

Re: clang warnings

Hi, Cloning the fresh GHC source, I can validate GHC HEAD on Linux. And I understand "install dir" is correct. The problem on Mac is that "ghc-clang-wrapper" is a shell script. I cannot find a way to treat strings, which includes spaces, correctly with shell scripts. So, I replaced "install d

Re: clang warnings

Hi Richard, > Would this fix #9047? Yay! I believe so. But currently "validate" itself fails: for i in driver/ghc-usage.txt driver/ghci-usage.txt includes/dist-derivedconsta nts/header/platformConstants settings; do case $i in *.a) /usr/bin/install -c -m 644 $i "/Users/kazu/work/ghc/b

Re: clang warnings

Would this fix #9047? Yay! On Jun 20, 2014, at 1:10 AM, Kazu Yamamoto (山本和彦) wrote: > Hi, > > I don't know whether or not this is new but it's worth sharing. > >> To test the coming GHC 7.8.3, I started to use the latest ghc-7.8 >> branch. Unfortunately, on

Re: clang warnings

Hi, I don't know whether or not this is new but it's worth sharing. > To test the coming GHC 7.8.3, I started to use the latest ghc-7.8 > branch. Unfortunately, on my Mac, I saw many warnings which are not > displayed with GHC 7.8.2: > > clang: warning: argument unused

Re: clang warnings

t; > To test the coming GHC 7.8.3, I started to use the latest ghc-7.8 > branch. Unfortunately, on my Mac, I saw many warnings which are not > displayed with GHC 7.8.2: > > clang: warning: argument unused during compilation: '-fno-stack-protector' > clang: war

clang warnings

Hi, To test the coming GHC 7.8.3, I started to use the latest ghc-7.8 branch. Unfortunately, on my Mac, I saw many warnings which are not displayed with GHC 7.8.2: clang: warning: argument unused during compilation: '-fno-stack-protector' clang: warning: argument unused during compil

Re: [commit: ghc] master: Deprecate the AMP warnings. (3608f65)

; | To: ghc-comm...@haskell.org > | Subject: [commit: ghc] master: Deprecate the AMP warnings. (3608f65) > | > | Repository : ssh://g...@git.haskell.org/ghc > | > | On branch : master > | Link : > | http://ghc.haskell.org/trac

RE: [commit: ghc] master: Deprecate the AMP warnings. (3608f65)

| Sent: 20 April 2014 22:56 | To: ghc-comm...@haskell.org | Subject: [commit: ghc] master: Deprecate the AMP warnings. (3608f65) | | Repository : ssh://g...@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/3608f657d55b7ea7dd711556a4faf | 6a15c509163

RE: core lint warnings when doing perf build of 7.8 tip

No. It’s just an infelicity I have never gotten around to removing Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Carter Schonwald Sent: 04 April 2014 21:43 To: ghc-devs@haskell.org Subject: core lint warnings when doing perf build of 7.8 tip should i be concerned

core lint warnings when doing perf build of 7.8 tip

should i be concerned about these? *** Core Lint warnings : in result of Simplifier *** {-# LINE 139 "compiler/deSugar/Check.lhs #-}: Warning: [RHS of Check.untidy :: Check.NeedPars -> Check.WarningPat -> Check.WarningPat] INLINE binder is (non

Re: Getting warnings when pushing to git.haskell.org

Try setting your locale to something like en_US.UTF-8: export LANG=en_US.UTF-8 unset LC_CTYPE * Johan Tibell [2014-03-11 22:15:16+0100] > Hi, > > I get the following warning every time I push to git.haskell.org. Anyone > have an idea what the correct fix is? > > $ git push origin master >

Getting warnings when pushing to git.haskell.org

Hi, I get the following warning every time I push to git.haskell.org. Anyone have an idea what the correct fix is? $ git push origin master perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LC_CTYPE = "UTF-8", LANG

Re: RTS warnings

On 2013-11-27 at 23:15:29 +0100, Gabor Greif wrote: [...] > PS: there is also this low-hanging fruit: > > libraries/containers/Data/IntSet/Base.hs:1196:17: Warning: > In the use of 'bitSize' (imported from Data.Bits): > Deprecated: "Use bitSizeMaybe or finiteBitSize instead" fyi, https:

RTS warnings

Hi all! I spottes these warnings in today's $ make INTEGER_LIBRARY=integer-simple V=0 build: rts/Stats.c: In function 'stat_exit': rts/Stats.c:695:0: warning: format '%16zu' expects type 'size_t', but argument 2 has type 'unsigned int' rt

Current link-destination Haddock warnings in base

Hello *, ...currently, when generating Haddock for `base` I see the warnings below; shall those warnings remain for GHC 7.8.1, or do we want to export (at least some of) the missing link destinations to reduce the amount of Haddock warnings? , | Warning: Data.Type.Coercion: could not find

Re: [commit: ghc] master: Fix AMP warnings for explicit Prelude imports (#8004) (b9127f4)

On 2013-09-30 04:00, Patrick Palka wrote: > + isPrelude :: ImportDecl Name -> Bool > + isPrelude = (== "Prelude") . moduleNameString . unLoc . ideclName > > Can't you just do unLoc (ideclName imp) == pRELUDE_NAME here? I think I hardcoded the name because I wanted to make sure not to run into th

Re: [commit: ghc] master: Fix AMP warnings for explicit Prelude imports (#8004) (b9127f4)

On Sun, Sep 29, 2013 at 9:10 PM, wrote: > +isPrelude :: ImportDecl Name -> Bool > +isPrelude = (== "Prelude") . moduleNameString . unLoc . ideclName Can't you just do unLoc (ideclName imp) == pRELUDE_NAME here? ___ ghc-devs mailing list ghc-d

Re: Can we make validate use the same warnings as make?

The former! On Mon, Sep 23, 2013 at 7:21 AM, Simon Marlow wrote: > On 22/09/2013 16:26, Johan Tibell wrote: >> >> In the past I've been frustrated by validate using other warnings than >> the default make build and also using -Werror. This causes a bit of >> frust

Re: Can we make validate use the same warnings as make?

On 22/09/2013 16:26, Johan Tibell wrote: In the past I've been frustrated by validate using other warnings than the default make build and also using -Werror. This causes a bit of frustration and lost time. If we used the same warnings I could have fixed the problem before a time cons

Can we make validate use the same warnings as make?

Hi, In the past I've been frustrated by validate using other warnings than the default make build and also using -Werror. This causes a bit of frustration and lost time. If we used the same warnings I could have fixed the problem before a time consuming validate. P.S. I just remember this

Re: "has no symbols"/"same member name" warnings using libtool

> > > > On Sat, Sep 14, 2013 at 2:12 AM, Edward Z. Yang wrote: > > Hey Luke, > > > > Please file a bug. Add static001 as a failing test case which is > > producing these errors. > > > > Thanks, > > Edward > > > > Excerpts from Luke Iannin

Re: "has no symbols"/"same member name" warnings using libtool

c001 as a failing test case which is > producing these errors. > > Thanks, > Edward > > Excerpts from Luke Iannini's message of Thu Sep 05 18:40:14 -0700 2013: >> Hi all, >> >> I'm trying to track down the last warnings in GHC iOS. >> >> W

Re: "has no symbols"/"same member name" warnings using libtool

Hey Luke, Please file a bug. Add static001 as a failing test case which is producing these errors. Thanks, Edward Excerpts from Luke Iannini's message of Thu Sep 05 18:40:14 -0700 2013: > Hi all, > > I'm trying to track down the last warnings in GHC iOS. > > We get t

  1   2   >