Opened 6 years ago

Closed 19 months ago

Last modified 16 months ago

#5273 closed feature request (fixed)

error and undefined should print a location

Reported by: augustss Owned by:
Priority: low Milestone: 8.0.1
Component: Compiler Version: 7.1
Keywords: Cc: bos@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: 9049 Differential Rev(s): Phab:D861
Wiki Page:


The Control.Exception.assert function has a very nice hack so it prints a location together with the message. Could we please have that feature for 'error' and 'undefined' as well?

I just had the case where in one of 83 installed packages some idiot has an error message that just says 'dataTypeConstrs', which makes it very tedious to figure out what to fix. Yes, I can recompile everything for profiling, but that takes another two hours, which is why I'd prefer location information. (BTW, hbc had location info for those.)

Change History (14)

comment:1 Changed 6 years ago by bos

Cc: bos@… added

comment:2 Changed 6 years ago by igloo

Milestone: 7.4.1

comment:3 Changed 5 years ago by igloo

Priority: normallow

comment:4 Changed 5 years ago by igloo


comment:5 Changed 3 years ago by MikolajKonarski

difficulty: Unknown

While we are at it, adding source position information to Debug.trace & Co would be very useful too (how often did you write 'trace "1" ... trace "2"', etc.?). This is done (in a hacky way, by passing assert as an argument) in the package loch from 2007, together with hacks for 'error' and exceptions. BTW, some support for locations in exceptions, without the need to profile for stack traces, would be very valuable too. Perhaps something can be done cheaply? Even just one random location sometimes?

This is all needed by people for years, because at least 3 packages contain relevant basic hacks (in addition to other stuff):

plus there are some more that use TH for that. *shudder*

Thank you in advance!

comment:6 Changed 3 years ago by thoughtpolice


Moving to 7.10.1.

comment:7 Changed 2 years ago by thoughtpolice


Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

comment:8 Changed 20 months ago by bgamari

Differential Rev(s): Phab:D861
Status: newpatch

This should be addressed by Phab:D861.

comment:9 Changed 20 months ago by edsko

comment:10 Changed 19 months ago by Ben Gamari <ben@…>

In 6740d70d/ghc:

Use IP based CallStack in error and undefined

This patch modifies `error`, `undefined`, and `assertError` to use
implicit call-stacks to provide better error messages to users.

There are a few knock-on effects:

- `GHC.Classes.IP` is now wired-in so it can be used in the wired-in
  types for `error` and `undefined`.

- `TysPrim.tyVarList` has been replaced with a new function
  `TysPrim.mkTemplateTyVars`. `tyVarList` made it easy to introduce
  subtle bugs when you need tyvars of different kinds. The naive

  tv1 = head $ tyVarList kind1
  tv2 = head $ tyVarList kind2

  would result in `tv1` and `tv2` sharing a `Unique`, thus substitutions
  would be applied incorrectly, treating `tv1` and `tv2` as the same
  tyvar. `mkTemplateTyVars` avoids this pitfall by taking a list of kinds
  and producing a single tyvar of each kind.

- The types `GHC.SrcLoc.SrcLoc` and `GHC.Stack.CallStack` now live in

- The type `GHC.Exception.ErrorCall` has a new constructor
  `ErrorCallWithLocation` that takes two `String`s instead of one, the
  2nd one being arbitrary metadata about the error (but usually the
  call-stack). A bi-directional pattern synonym `ErrorCall` continues to
  provide the old API.

Updates Cabal, array, and haddock submodules.

Reviewers: nh2, goldfire, simonpj, hvr, rwbarton, austin, bgamari

Reviewed By: simonpj

Subscribers: rwbarton, rodlogic, goldfire, maoe, simonmar, carter,
liyang, bgamari, thomie

Differential Revision:

GHC Trac Issues: #5273

comment:11 Changed 19 months ago by bgamari

Resolution: fixed
Status: patchclosed

comment:12 Changed 19 months ago by bgamari

One remaining question here is how this should interact with DWARF-based stacktraces (see Phab:D1198). The two mechanisms exhibit different strengths,

  • IP-based stacktraces:
    • Always accurate
    • Cheap to gather stack but have small effect on code generation
    • Can only provide limited stack depth
  • DWARF-based stacktraces:
    • May not point you at exactly the right place
    • More expensive to gather stack but no effect on code generation
    • Can provide full stack (but perhaps it's best if we capped the depth to avoid costly unwinding of deep stacks)
    • Requires that code be built with -g

Given they are to some extent complementary, perhaps we should produce both if available?

Note: technically there are two costs to DWARF stack collection:

  1. Unwinding the stack: the task of actually walking the stack and collection the relevant addresses
  2. Looking up the addresses: the task of looking up symbol names and source location information for the addresses we collected in step 1.

In my experience (2) tend to be much more expensive than (1). In Phab:D1198 step (2) should occur lazily, so it will only be paid if the necessary. Step (1) however necessarily happens unconditionally.

comment:13 Changed 19 months ago by thoughtpolice


Milestone renamed

comment:14 Changed 16 months ago by Herbert Valerio Riedel <hvr@…>

In 9f4ca5a/ghc:

Associate ErrorCall pattern with ErrorCall type

This way,

    import Control.Exception (ErrorCall(ErrorCall))


    import Control.Exception (ErrorCall(..))

work as expected, and import the `ErrorCall` compatibility pattern as well.

When #5273 was implemented, it wasn't possible yet to associated
patterns with their types (see #10653).

Reviewed By: austin

Differential Revision:
Note: See TracTickets for help on using tickets.