<emphasis>not</emphasis> enabled by <option>-Wall</option>
are
<option>-fwarn-tabs</option>,
+ <option>-fwarn-incomplete-uni-patterns</option>,
<option>-fwarn-incomplete-record-updates</option>,
<option>-fwarn-monomorphism-restriction</option>,
- <option>-fwarn-unused-do-bind</option>, and
+ <option>-fwarn-unrecognised-pragmas</option>,
+ <option>-fwarn-auto-orphans</option>,
<option>-fwarn-implicit-prelude</option>.</para>
</listitem>
</varlistentry>
</varlistentry>
<varlistentry>
- <term><option>-fwarn-incomplete-patterns</option>:</term>
+ <term><option>-fwarn-incomplete-patterns</option>,
+ <option>-fwarn-incomplete-uni-patterns</option>:
+ </term>
<listitem>
<indexterm><primary><option>-fwarn-incomplete-patterns</option></primary></indexterm>
+ <indexterm><primary><option>-fwarn-incomplete-uni-patterns</option></primary></indexterm>
<indexterm><primary>incomplete patterns, warning</primary></indexterm>
<indexterm><primary>patterns, incomplete</primary></indexterm>
- <para>Similarly for incomplete patterns, the functions
- <function>g</function> and <function>h</function> below will fail when applied to
+ <para>The option <option>-fwarn-incomplete-patterns</option> warns
+ about places where
+ a pattern-match might fail at runtime.
+ The function
+ <function>g</function> below will fail when applied to
non-empty lists, so the compiler will emit a warning about
this when <option>-fwarn-incomplete-patterns</option> is
- enabled.</para>
-
+ enabled.
<programlisting>
g [] = 2
-h = \[] -> 2
</programlisting>
-
- <para>This option isn't enabled by default because it can be
+ This option isn't enabled by default because it can be
a bit noisy, and it doesn't always indicate a bug in the
program. However, it's generally considered good practice
- to cover all the cases in your functions.</para>
+ to cover all the cases in your functions, and it is switched
+ on by <option>-W</option>.</para>
+
+ <para>The flag <option>-fwarn-incomplete-uni-patterns</option> is
+ similar, except that it
+ applies only to lambda-expressions and pattern bindings, constructs
+ that only allow a single pattern:
+<programlisting>
+h = \[] -> 2
+Just k = f y
+</programlisting>
+ </para>
</listitem>
</varlistentry>
</varlistentry>
<varlistentry>
+ <term>
+ <option>-fwarn-missing-import-lists</option>:
+ <indexterm><primary><option>-fwarn-import-lists</option></primary></indexterm>
+ <indexterm><primary>missing import lists, warning</primary></indexterm>
+ <indexterm><primary>import lists, missing</primary></indexterm>
+ </term>
+ <listitem>
+
+ <para>This flag warns if you use an unqualified
+ <literal>import</literal> declaration
+ that does not explicitly list the entities brought into scope. For
+ example
+ </para>
+<programlisting>
+module M where
+ import X( f )
+ import Y
+ import qualified Z
+ p x = f x x
+</programlisting>
+ <para>
+ The <option>-fwarn-import-lists</option> flag will warn about the import
+ of <literal>Y</literal> but not <literal>X</literal>
+ If module <literal>Y</literal> is later changed to export (say) <literal>f</literal>,
+ then the reference to <literal>f</literal> in <literal>M</literal> will become
+ ambiguous. No warning is produced for the import of <literal>Z</literal>
+ because extending <literal>Z</literal>'s exports would be unlikely to produce
+ ambiguity in <literal>M</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
<term><option>-fwarn-missing-methods</option>:</term>
<listitem>
<indexterm><primary><option>-fwarn-missing-methods</option></primary></indexterm>
<para>We don't use a <option>-O*</option> flag for day-to-day
work. We use <option>-O</option> to get respectable speed;
e.g., when we want to measure something. When we want to go for
- broke, we tend to use <option>-O2 -fvia-C</option> (and we go for
+ broke, we tend to use <option>-O2</option> (and we go for
lots of coffee breaks).</para>
<para>The easiest way to see what <option>-O</option> (etc.)
</para>
</listitem>
</varlistentry>
- <varlistentry>
- <term><option>-qw</option></term>
- <indexterm><primary><option>-qw</option></primary><secondary>RTS
- option</secondary></indexterm>
- <listitem>
- <para>Migrate a thread to the current CPU when it is woken
- up. Normally when a thread is woken up after being
- blocked it will be scheduled on the CPU it was running on
- last; this option allows the thread to immediately migrate
- to the CPU that unblocked it.</para>
-
- <para>The rationale for allowing this eager migration is
- that it tends to move threads that are communicating with
- each other onto the same CPU; however there are
- pathalogical situations where it turns out to be a poor
- strategy. Depending on the communication pattern in your
- program, it may or may not be a good idea.</para>
- </listitem>
- </varlistentry>
</variablelist>
</sect2>
</listitem>
</varlistentry>
- <varlistentry>
- <term><option>-monly-[32]-regs</option>:</term>
- <listitem>
- <para>(x86 only)<indexterm><primary>-monly-N-regs
- option (iX86 only)</primary></indexterm> GHC tries to
- “steal” four registers from GCC, for performance
- reasons; it almost always works. However, when GCC is
- compiling some modules with four stolen registers, it will
- crash, probably saying:
-
-<screen>
-Foo.hc:533: fixed or forbidden register was spilled.
-This may be due to a compiler bug or to impossible asm
-statements or clauses.
-</screen>
-
- Just give some registers back with
- <option>-monly-N-regs</option>. Try `3' first, then `2'.
- If `2' doesn't work, please report the bug to us.</para>
- </listitem>
- </varlistentry>
</variablelist>
</sect1>
<filename>.hcr</filename>. The Core format is described in <ulink url="../../core.pdf">
<citetitle>An External Representation for the GHC Core Language</citetitle></ulink>,
and sample tools
- for manipulating Core files (in Haskell) are in the GHC source distribution
- directory under <literal>utils/ext-core</literal>.
- Note that the format of <literal>.hcr</literal>
+ for manipulating Core files (in Haskell) are available in the
+ <ulink url="http://hackage.haskell.org/package/extcore">extcore package on Hackage</ulink>. Note that the format of <literal>.hcr</literal>
files is <emphasis>different</emphasis> from the Core output format that GHC generates
for debugging purposes (<xref linkend="options-debugging"/>), though the two formats appear somewhat similar.</para>