Opened 11 years ago

Last modified 23 months ago

#1231 new feature request

deprecation warnings are reported too often

Reported by: malcolm.wallace@… Owned by: simonpj
Priority: low Milestone:
Component: Compiler Version: 6.6
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Incorrect warning at compile-time Test Case: nhc98/src/compiler98
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

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.

Change History (11)

comment:1 Changed 11 years ago by simonpj

This is very easy to change, but I'm not sure it's a good change. Malcolm's proposal is:

If module M mentions a deprecated function f, which is defined in module F, a warning is given ONLY IF M directly imports F.

An example of why you might not want this behaviour is as follows. A package defines lots of functions in lots of modules, but has a module X "at the top" which gathers all the modules and re-exports all the functions the package wants to expose. Now clients of the package need only import X. But we still want clients to see deprecation messages when they use the deprecated function.

Perhaps this modification would do the job?

If module M mentions a deprecated function f, which is defined in module F, a warning is given ONLY IF either (a) M directly imports F, or (b) the import that brought f into scope was for a non-home-package module.

Discuss.

Simon

comment:2 Changed 11 years ago by malcolm.wallace@…

The latter suggestion seems reasonable to me. i.e. also warn when the import crosses a package boundary.

comment:3 Changed 11 years ago by igloo

Milestone: 6.6.2

comment:4 Changed 11 years ago by simonmar

Milestone: 6.6.26.8
Priority: normallow
Type: bugfeature request

comment:5 Changed 11 years ago by malcolm.wallace@…

SimonPJ asked:

Since you are the one who tripped over this, would you like to draft some new text for the user manual, that describes precisely when a deprecation warning is emitted? Then I'll implement it. Start with the text here: http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#deprecated-pragma

My suggestion is to change the penultimate paragraph which currently reads:

Any use of the deprecated item, or of anything from a deprecated module, will be flagged with an appropriate message. However, deprecations are not reported for (a) uses of a deprecated function within its defining module, and (b) uses of a deprecated function in an export list. The latter reduces spurious complaints within a library in which one module gathers together and re-exports the exports of several others.

to

Any use of the deprecated item, or of anything from a deprecated module, will be flagged with an appropriate message. However, deprecations are not reported for uses of a deprecated entity (a) within its defining module, (b) within an export list, or (c) in a module that imports the entity from another module in the same package, but where the entity was originally defined in a different package. Conditions (b) and (c) reduce spurious complaints within a library in which one module gathers together and re-exports the exports of several others.

comment:6 Changed 11 years ago by simonpj

Owner: set to simonpj

comment:7 Changed 10 years ago by igloo

Milestone: 6.8 branch_|_

comment:8 Changed 9 years ago by simonmar

Architecture: MultipleUnknown/Multiple

comment:9 Changed 9 years ago by simonmar

Operating System: MultipleUnknown/Multiple

comment:10 Changed 5 years ago by morabbin

Type of failure: None/Unknown

Docs for 7.6.1 now read:

Warnings and deprecations are not reported for (a) uses within the defining module, and (b) uses in an export list. The latter reduces spurious complaints within a library in which one module gathers together and re-exports the exports of several others.

which seems to be equivalent to Malcolm's "before", not his "after".

comment:11 Changed 23 months ago by thomie

Type of failure: None/UnknownIncorrect warning at compile-time
Note: See TracTickets for help on using tickets.