... | ... | @@ -2,33 +2,29 @@ |
|
|
|
|
|
---
|
|
|
|
|
|
**TODO** This page is possibly outdated. Update to the latest information.
|
|
|
|
|
|
See also [Issue conventions](https://gitlab.haskell.org/ghc/ghc/wikis/gitlab/issues)
|
|
|
|
|
|
---
|
|
|
|
|
|
Glasgow Haskell is a changing system so there are sure to be bugs in it.
|
|
|
GHC is a changing system so there are sure to be bugs in it.
|
|
|
|
|
|
|
|
|
To report a bug, either:
|
|
|
|
|
|
- Preferred:
|
|
|
|
|
|
- register an account on this GitLab instance
|
|
|
- Create a [new bug](https://gitlab.haskell.org/ghc/ghc/issues), and enter your bug report. You can also search the bug database here to make sure your bug hasn't already been reported (if it has, it might still help to add information from your experience to the existing report).
|
|
|
- register an account on this GitLab instance
|
|
|
- Create a [new bug](https://gitlab.haskell.org/ghc/ghc/issues), and enter your bug report. Make a new ticket for your bug unless you are 100% sure there is a ticket for your exact problem.
|
|
|
|
|
|
|
|
|
## How do I tell if I should report my bug?
|
|
|
|
|
|
- **Is it a bug at all?**. Take a look at the [FAQ](http://haskell.org/haskellwiki/GHC/FAQ) and [What to do when something goes wrong](http://www.haskell.org/ghc/docs/latest/html/users_guide/gone_wrong.html) from the GHC User's Guide, which will give you some guidance as to whether the behaviour you're seeing is really a bug or not.
|
|
|
|
|
|
- **Duplicate bug reports**. Please search for existing tickets on the [bug tracker](https://gitlab.haskell.org/ghc/ghc/issues) (search box in top right hand corner) or [ Google](http://www.google.com/?q=site:ghc.haskell.org/trac/ghc/ticket%20). If your problem has already been reported, it saves time to have all the manifestations of the same bug gathered together. If you get an error message from GHC, a good search key is usually the non-program-specific part of the error message.
|
|
|
- **Duplicate bug reports**. Please search for existing tickets on the [bug tracker](https://gitlab.haskell.org/ghc/ghc/issues) (search box in top right hand corner) or [Google](http://www.google.com/?q=site:ghc.haskell.org/trac/ghc/ticket%20). If your problem has already been reported, it saves time to have all the manifestations of the same bug gathered together. If you get an error message from GHC, a good search key is usually the non-program-specific part of the error message.
|
|
|
|
|
|
If you do find an existing ticket that seems to describe the same problem, then
|
|
|
|
|
|
- Add a comment that explains how it manifests for you, and add your description of how to reproduce it (see below)
|
|
|
- Add yourself to the CC list for the bug. We will try to prioritise bugs that affect a lot of people, and the length of the CC list is how we are currently determining this. Use a comma or space (but not semicolon) to separate your email address from the next one.
|
|
|
- Subscribe to notifications for the ticket. We will try to prioritise bugs that affect a lot of people.
|
|
|
|
|
|
- **RTS bugs**. However, if you encounter a crash from the runtime system, then don't bother searching for existing tickets - just create a new ticket. These indicate a general RTS failure of some kind, and can arise due to a wide range of causes, so it is easier for us to track each failure in a separate ticket.
|
|
|
|
... | ... | @@ -47,35 +43,8 @@ To report a bug, either: |
|
|
- **If in doubt, just report your bug**.
|
|
|
|
|
|
## What to put in a bug report
|
|
|
|
|
|
|
|
|
The Trac bug report system has various fields. Here's how to fill them in:
|
|
|
|
|
|
- **Short summary**. This is what appears in one-bug-per line lists, so try to make it as informative as you can. A snippet of the error message, if there is one, usually makes a good summary.
|
|
|
|
|
|
- **Type** says what kind of Trac ticket this is:
|
|
|
|
|
|
- **bug**: incorrect behaviour by GHC
|
|
|
- **feature request**: something you would like GHC to do
|
|
|
- **task** (for use by GHC developers only): something we intend to do sometime
|
|
|
|
|
|
- **Full description**. This is where you describe your bug in details. See "What information to provide" below. Use the [wiki markup](trac-wiki-misc) in your description, especially `{{{` ... `}}}` brackets to mark up literal code.
|
|
|
|
|
|
- **CC**. If you are only logged in as *guest* then please consider including your email address (using a comma or space as separator, not a semicolon). That way we can ask you questions, and you'll get email from Trac when something happens to your bug.
|
|
|
|
|
|
- **Operating system** and **Architecture**. Only fill these in if you think the bug is platform dependent. Otherwise, use `Unknown/Multiple`.
|
|
|
|
|
|
- **Component** and **Version**. Please pay particular attention to **version**, which is the version of GHC that you are running. Ideally, the version field is used to denote the first version a bug/issue is known to exist in (regardless whether that version is "supported" or not).
|
|
|
|
|
|
- **Priority**, **Milestone**, **Assign to**, **Difficulty**, **Test case**, **Blocking**, **Blocked by**: these are all for use by GHC developers; please don't fill these in.
|
|
|
|
|
|
|
|
|
See also [GHC working conventions](contributing).
|
|
|
|
|
|
|
|
|
## Full description: what information to provide in the body of your bug report
|
|
|
|
|
|
|
|
|
The name of the bug-reporting game is: facts, facts, facts. Don't omit them because "Oh, they won't be interested…".
|
|
|
|
|
|
**The absolutely key thing is that we must be able to reproduce the bug**. Without this, we are virtually helpless; we know there's a problem but we usually can make no progress with fixing it. The easiest way to help us reproduce the bug is to provide us with a program that elicits it:
|
... | ... | |