Qualified Names in --show-iface output

Motivation

In the Hi Haddock project we use tests based on the --show-iface mode.

In the .hi-files we dump, we list the Names that may correspond to an identifier found in a docstring. In the case of ambiguous identifiers, it would be nice to see the module names of the corresponding Names, so we can tell them apart.

For example, for a module containing a docstring "'elem'" and a declaration for elem, we would currently see:

"elem":
  elem
  elem

One elem refers to the local one, the other to the one in the Prelude.

What I'd like to see instead is

"elem":
  Data.Foldable.elem
  MyModule.elem

If the output would also contain package names and/or ids, I wouldn't mind.

Possible solutions

• In D4806, I proposed to hardcode qualification for --show-iface. But this may create unwanted noise in different usecases.
• If I could use -dppr-debug with --show-iface I would do that. Currently I get the following error if try:

Warning: the following files would be used as linker inputs, but linking is not being done: NoExportList.hi -dppr-debug: openBinaryFile: does not exist (No such file or directory)

changed milestone to %8.8.1

changed weight to 5

added Tfeature request Trac import labels

It would help me to understand what you are proposing if you could give an example of what you currently get with --show-iface and what you'd like to get instead.

Also, is it really best to work from a textual dump? You could instead use the GHC API to load the .hi file into memory, and interrogate it directly, perhaps?

changed the description

It would help me to understand what you are proposing if you could give an example of what you currently get with --show-iface and what you'd like to get instead.

I have updated the description.

Also, is it really best to work from a textual dump? You could instead use the GHC API to load the .hi file into memory, and interrogate it directly, perhaps?

I'm not sure how to integrate tests like that into the GHC testsuite. Also, apart from this issue, --show-iface works pretty well for me.

In ​Phab:D4806, I proposed to hardcode qualification for --show-iface. But this may create unwanted noise in different usecases.

I'm wondering if it might be more acceptable if I limit the hardcoded qualification to the the area of interest to me? I just found out about withPprStyle.

I didn't know this, but indeed --show-iface doesn't seem to show qualified names, which is confusing in unfoldings. (It might be reasonable not to quality names from the current module.)

This is controlled by the pretty-printing style. I'm not sure how --show-iface invokes the pretty-printer, but it looks as though defaultUserStyle omits the module qualifier on everything, which isn't what we want here

defaultUserStyle :: DynFlags -> PprStyle
defaultUserStyle dflags = mkUserStyle dflags neverQualify AllTheWay

Note that neverQualify.

So I think you could fix it for all of --show-iface not just for docstring.

--show-iface is implemented in showIface and uses defaultDumpStyle dflags, which in turn uses neverQualify:

defaultDumpStyle :: DynFlags -> PprStyle
 -- Print without qualifiers to reduce verbosity, unless -dppr-debug
defaultDumpStyle dflags
   | hasPprDebug dflags = PprDebug
   | otherwise          = PprDump neverQualify

I think I'll try to make a custom PrintUnqualified style that qualifies (with module names) any names that are not defined in the current module, and apply this style to the entire --show-iface output.

Does this sound like a good idea?

Yes, sounds good to me.

Trac metadata

Trac field	Value
Differential revisions	- → D4852

I realized that I don't know the right terminology for names from the current module and names from other modules. Is there any? If not, are "local" and "non-local" names good words for this?

I realized that I don't know the right terminology for names from the current module and names from other modules. Is there any? If not, are "local" and "non-local" names good words for this?

A difficulty is that being "from the current module" is not a property of a Name; it's a property of the Name plus the module being compiled; see nameIsLocalOrFrom.

See also Var.hs:

Note [GlobalId/LocalId]
~~~~~~~~~~~~~~~~~~~~~~~
A GlobalId is
  * always a constant (top-level)
  * imported, or data constructor, or primop, or record selector
  * has a Unique that is globally unique across the whole
    GHC invocation (a single invocation may compile multiple modules)
  * never treated as a candidate by the free-variable finder;
        it's a constant!

A LocalId is
  * bound within an expression (lambda, case, local let(rec))
  * or defined at top level in the module being compiled
  * always treated as a candidate by the free-variable finder

After CoreTidy, top-level LocalIds are turned into GlobalIds

So isLocalId will reply True to a name defined in the current module up to CoreTidy, but not after. And all the interface stuff is after.

Because of this contextual complexity, I suggest you spell out what you mean when you say it.

mentioned in commit d42eef34

I'm not sure if this is mergable.

added 1 deleted label

changed milestone to %8.6.1

Sure, it's simple enough and useful while debugging.

closed

removed 1 deleted label

Merged in c69c9d39.

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

added Pnormal label