haskellfoundation / error-message-index Goto Github PK

View Code? Open in Web Editor NEW

97.0 8.0 64.0 1.26 MB

A community-driven collection of documentation for Haskell error messages and warnings

Home Page: https://errors.haskell.org

CSS 8.87% HTML 9.21% Shell 2.22% Haskell 79.71%

haskell

error-message-index's Introduction

The Haskell Message Index

View the site → https://errors.haskell.org/

Haskell tooling emits a variety of errors, warnings, and other messages. In recent versions, some of these tools emit a unique code for each message that allows it to be identified. This site allows these codes to be looked up, providing examples, context, and further information that can make them easier to understand.

Supported Tools

Today, the Haskell Message Index supports three tools. Any user-facing Haskell-related programming tools are welcome to join the effort!

Tool	Earliest supported version	Namespace
GHC	9.6.1	`GHC-`
Stack	2.9.3	`S-`
GHCup	0.1.19.0	`GHCup-`
Cabal	3.12	`Cabal-`

Contributing to the Message Index

Contributions may come in the form of changes to the code base, as well as opening or commenting on issues and pull requests. You are warmly invited to participate!

Please see CONTRIBUTING.md for instructions on improving the site. Thanks!

If you're a Haskell tool developer who would like to integrate your project with the site, please refer to tool-developers.md for recommendations regarding the error codes themselves.

Maintenance

The Message Index is a project of the Haskell Foundation, maintained on a volunteer basis by David Binder (@BinderDavid). Please get in touch if you have ideas, requests, or any other feedback!

error-message-index's People

Contributors

Stargazers

Watchers

error-message-index's Issues

Examples should be opened by default

To reproduce: go to any page; the example requires a click to open the dropdown.

Expected: it's just much nicer to read if the example is automatically expanded.

`TcRnUserTypeError` 47403 should be folded into `UserTypeError` 64725

TcRnUserTypeError (47403) and UserTypeError (64725) really are the same error, but they get triggered in different parts of the compiler. At first I thought one was specifically for constraints and the other one for type families, but it's more subtle than that (in some cases, adding/removing a type signature changes which one you get), but for the user it really doesn't make a difference. If they had the same error code, that wouldn't be a problem. Another alternative would be to allow redirections, so e.g. the link for TcRnUserTypeError (47403) simply redirects to the page for UserTypeError (64725).

On the global index, order the numbers numerically, not lexicographically.

This is me being OCD, but prefer "3, 5, 11, 43" over "11, 3, 43, 5" :)

DsMultipleConForNewtype -> 5380

DsIdentitiesFound -> 4214

PsErrParseErrorInCmd -> 3790

Explain the "Introduced" field on the home page

It's for the code, not the error itself, and this should be made clear to readers.

[Tasks] All tasks

Tidied up Alejandro's excellent lists and also sorted them numerically

Tc is from GHC.Tc.Errors.Ppr

Driver is from GHC.Driver.Errors.Ppr

Ps is from GHC.Parser.Errors.Ppr

Ds is from GHC.HsToCore.Errors.Ppr

TcRnExpectedValueId -> 1570

[Tasks] Type checker errors

From GHC.Tc.Errors.Ppr

TcRnDuplicateWarningDecls -> 711

DriverHomePackagesNotClosed -> 3271

TcRnDerivingDefaults -> 20042

Trailing whitespace should be trimmed for neatness

Consider this: https://haskell.github.io/error-messages/messages/GHC-99623/example1/index.html

because the before has an extra trailing newline, the alignment is thrown off. This should probably be formatted the same way

PsErrLambdaCase & PsErrEmptyLambda

PsErrLambdaCase{} -> Just 51179
PsErrEmptyLambda{} -> Just 71614

Code blocks don't respect screen width on mobile

On the error details page, code blocks (for file name, error message, and before/after code) don't respect the screen width on mobile devices, as can be seen in the following screenshots.

Coherency in structure

Do we want to have consistency in the following ideas?

module Main, module Example, module SpecificToThisErrorMessage, no module? (I personally think no module is best)
Should we be writing ideal Haskell; i.e. with top-level signatures?
Error messages in the index.md?

DerivErrNullaryClasses -> 4956

TcRnIllegalForeignDeclBackend -> 3355

TcRnFamInstNotInjective -> 5175

Meta: We should make it easier to pick up single issues for people who weren't at Zurihac

We have that very big list of tasks, but this isn't very clear.

We can convert these to individually tracked issues - e.g. #294 - which means there does not need to be someone with write access to continually update the list.

We could also get some kind of automatic triaging bot to then assign these labels (project:error-index perhaps?). We could then have further human triaging - linking to relevant tests in GHC, tagging easy issues as low hanging fruit (e.g. "parse error: construct where it should not be").

I've done something similar at work (I proposed a new triage system, I got the go ahead, and I implemented it).

My concrete proposal:

Link every individual point to an issue
Mark up those of which are easy to pickup
Make it clear how people can document, help, etc. when not necessarily having the time to commit an entire code.

[Tasks] Driver errors

From GHC.Driver.Errors.Ppr

Server logs

We should figure out how to monitor which pages are most popular to focus efforts.

TcRnUnsafeDueToPlugin -> 1687

There should be a `flag` field in the metadata which indicates the corresponding -Wxxx flag.

The current examples for warnings don't contain a metadata flag for the corresponding flag which has to be passed to GHC in order to enable the warning.

E.g.

--
ghc-flag: WmissingFields
--

PsErrProcInFunAppExpr -> 4807

TcRnImplicitLift -> 846

TcRnUnsupportedCallConv -> 1245

GHC-00158 should have an example using DerivingStrategies

TcRnBadQuantPredHead -> 2550

PsErrImportQualifiedTwice -> 5661

Add an example of conflicting imports that doesn't exclusively use qualified names

In haskell/error-messages#100 I only did an example where both names are imported qualified, but I think the error would also be triggered by something like

module Greeting (W.greeting, greeting) where

import qualified World as W
import Universe (greeting)

and

module Greeting (W.greeting, module Universe) where

import qualified World as W
import Universe (greeting)

so doing at least one of those would probably be useful.

90177 should have an example where orphans cause instance incoherence

We couldn't think up a testcase which causes the nukes to be launched (or a runtime crash) due to orphan instance issues.

PsErrIfInFunAppExpr -> 1239

PsErrArrowExprInPat -> 4584

SkolemEscape -> 83865

Decide on method for documenting .cabal or package errors

Many of the Driver errors are to do with .cabal or otherwise project-wide (rather than being an error in a .hs). We should work out how to handle these.

PsErrLambdaCaseInPat -> 7636

[idea] color-diff the before- and after-example

would make it more convenient to spot the difference.

Parse errors: <thing> in pattern (PsErrFooInPat)

This is a solid block of 7 or 8 parse errors. Just claiming dibs :)

[Tasks] Parser errors

From GHC.Parser.Errors.Ppr

[Tasks] Desugarer errors

From GHC.HsToCore.Errors.Ppr

Seemingly-redundant error codes

Presently, both [GHC-76037] (TcRnNotInScope) and [GHC-88464] (TcSolverReport (SolverReportWithCtxt { reportContent = ReportHoleError ...) give very similar string messages, but are distinct:

<interactive>:2:7: error: [GHC-88464]
    Data constructor not in scope: X
ghci> \X -> X

<interactive>:3:2: error: [GHC-76037]
    Not in scope: data constructor ‘X’

We should follow up with the GHC folks about whether these should have the same code.