Used to just give a "Non-exhaustive patterns" failure
Argubly rewrite rules should not fire with -O0, and it turns out that when compiling GHC.Base with -O0 we get a crash if the rewrite rules do fire (see Note [Scoping for Builtin rules] in PrelRules). So unless someone yells, rewrite rules are off with -O0. The new (now dynamic) flag is -frewrite rules (with -fno-rewrite-rules to disable) The old (static) flag -frules-off is gone.
This fixes Trac #1251; test case is gadt/CasePrune GHC was being over-eager about pruning dead alternatives from case expressions, and that led to a crash because the case expression ended up with no alternatives at all! See the long comments Note [Pruning dead case alternatives] in Unify.
…ilies isDataTyCon advertises that it's true of "data types that are definitely represented by heap-allocated constructors. These are srcutinised by Core-level @case@ expressions, and they get info tables allocated for them." Type-family TyCons never have this property, not even data type families. It's the *instance* TyCons that do. I hope that this change does not break anything that somehow relied on the old (wrong) semantics.
A SpecInfo (inside IdInfo) keeps track of the free variables of a RULE so that the occurrency analyser knows about its dependencies. Previously it was only tracking the *rhs* free vars, but it should really include the *lhs* ones too. See Note [Rule dependency info] in IdInfo. This fixes a WARNING when compiling some libraries.
…I call This means we can avoid some StablePtrs, and also catch cases where the AP_STACK has been evaluated (this can happen with :history, see the hist001 test).
We don't touch $@ if configure failed as we would prefer to try configuring it next time round, rather than assuming it'll still fail. This is particularly important for corelibs, where failure means the build dies!
The debugger can now log each step of the evaluation without actually stopping, keeping a history of the recent steps (currently 50). When a (real) breakpoint is hit, you can examine previous steps in the history (and their free variables) using the :history, :back and :forward commands.
-ticky is the command-line flag for ticky-ticky profiling now, but internally, the -fticky-ticky flag was used to represent whether ticky was on. This led to link errors if the user supplied -fticky-ticky but not -ticky (ticky code would be generated but the wrong RTS library would be passed to the linker). I removed references to -fticky-ticky -- now, only the way flags dictate whether ticky is on, and -fticky-ticky is no longer accepted as a command-line option.