[GHC] #1231: deprecation warnings are reported too often

GHC trac at galois.com
Fri Mar 16 07:18:44 EDT 2007


#1231: deprecation warnings are reported too often
----------------------------------------------+-----------------------------
    Reporter:  malcolm.wallace at cs.york.ac.uk  |       Owner:                      
        Type:  bug                            |      Status:  new                 
    Priority:  normal                         |   Milestone:                      
   Component:  Compiler                       |     Version:  6.6                 
    Severity:  normal                         |    Keywords:                      
  Difficulty:  Unknown                        |    Testcase:  nhc98/src/compiler98
Architecture:  Multiple                       |          Os:  Multiple            
----------------------------------------------+-----------------------------
Not so much a bug, more an annoyance.

 In some code which is designed to work on multiple compiler platforms,
 there are some system dependencies such as the name/location of non-
 standard libraries.  Accordingly, I gather all such deps into a single
 module SysDeps.hs, which is heavily reliant on cpp #ifdefs, but whose only
 purpose is to re-export the non-standard entities needed by the rest of
 the project.  So far so good.  Now it turns out that ghc-6.6 has
 deprecated some of the non-standard libraries.  Fair enough, I would
 expect to see the deprecation warnings when I compile SysDeps.hs.  But in
 fact, I see multiple deprecation warnings - one for every deprecated
 entity, used in any module.  So instead of seeing 5 or so warnings, nicely
 localised to a single module, I see 40 or so, smeared out across the whole
 project.

 An example:
 {{{
 Import.hs:9:28:
     Warning: Deprecated use of `unpackPS'
              (imported from SysDeps, but defined in Data.PackedString):
              use Data.ByteString, Data.ByteString.Char8, or plain String.
 }}}

 As you can see, the warning mechanism is aware that it is doing a
 transitive closure over imports.  But really, I'd prefer it not to, and
 instead to report the deprecation only in the directly-importing module.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1231>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler


More information about the Glasgow-haskell-bugs mailing list