Options can be specified in three ways:</para>
<sect2>
- <title>command-line arguments</title>
+ <title>Command-line arguments</title>
<indexterm><primary>structure, command-line</primary></indexterm>
<indexterm><primary>command-line</primary><secondary>arguments</secondary></indexterm>
ghc [argument...]
</screen>
- <para>command-line arguments are either options or file names.</para>
+ <para>Command-line arguments are either options or file names.</para>
- <para>command-line options begin with <literal>-</literal>.
+ <para>Command-line options begin with <literal>-</literal>.
They may <emphasis>not</emphasis> be grouped:
<option>-vO</option> is different from <option>-v -O</option>.
Options need not precede filenames: e.g., <literal>ghc *.o -o
</sect2>
<sect2 id="source-file-options">
- <title>command line options in source files</title>
+ <title>Command line options in source files</title>
<indexterm><primary>source-file options</primary></indexterm>
<para>It is not recommended to move all the contents of your
Makefiles into your source files, but in some circumstances, the
<literal>OPTIONS_GHC</literal> pragma is the Right Thing. (If you
- use <option>-keep-hc-file-too</option> and have OPTION flags in
+ use <option>-keep-hc-file</option> and have OPTION flags in
your module, the OPTIONS_GHC will get put into the generated .hc
file).</para>
</sect2>
<indexterm><primary>mode</primary><secondary>options</secondary>
</indexterm>
- <para>Each of GHC's command line options is classified as either
- <firstterm>static</firstterm> or <firstterm>dynamic</firstterm> or
+ <para>Each of GHC's command line options is classified as
+ <firstterm>static</firstterm>, <firstterm>dynamic</firstterm> or
<firstterm>mode</firstterm>:</para>
<variablelist>
<term>Mode flags</term>
<listitem>
<para>For example, <option>--make</option> or <option>-E</option>.
- There may be only a single mode flag on the command line. The
+ There may only be a single mode flag on the command line. The
available modes are listed in <xref linkend="modes"/>.</para>
</listitem>
</varlistentry>
<listitem><option>-fwarn-tabs</option></listitem>
<listitem><option>-fwarn-incomplete-record-updates</option></listitem>
<listitem><option>-fwarn-monomorphism-restriction</option></listitem>
+ <listitem><option>-fwarn-implicit-prelude</option></listitem>
</itemizedlist>
</listitem>
</varlistentry>
</varlistentry>
<varlistentry>
+ <term><option>-fwarn-implicit-prelude</option>:</term>
+ <listitem>
+ <indexterm><primary><option>-fwarn-implicit-prelude</option></primary></indexterm>
+ <indexterm><primary>implicit prelude, warning</primary></indexterm>
+ <para>Have the compiler warn if the Prelude is implicitly
+ imported. This happens unless either the Prelude module is
+ explicitly imported with an <literal>import ... Prelude ...</literal>
+ line, or this implicit import is disabled (either by
+ <option>-fno-implicit-prelude</option> or a
+ <literal>LANGUAGE NoImplicitPrelude</literal> pragma).</para>
+
+ <para>Note that no warning is given for syntax that implicitly
+ refers to the Prelude, even if <option>-fno-implicit-prelude</option>
+ would change whether it refers to the Prelude.
+ For example, no warning is given when
+ <literal>368</literal> means
+ <literal>Prelude.fromInteger (368::Prelude.Integer)</literal>
+ (where <literal>Prelude</literal> refers to the actual Prelude module,
+ regardless of the imports of the module being compiled).</para>
+
+ <para>This warning is off by default.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
<term><option>-fwarn-incomplete-patterns</option>:</term>
<listitem>
<indexterm><primary><option>-fwarn-incomplete-patterns</option></primary></indexterm>
<para>Note that higher optimisation levels cause more
cross-module optimisation to be performed, which can have an
impact on how much of your program needs to be recompiled when
- you change something. This is one reaosn to stick to
+ you change something. This is one reason to stick to
no-optimisation when developing code.</para>
<variablelist>
<varlistentry>
<term>
+ <option>-fno-state-hack</option>
+ <indexterm><primary><option>-fno-state-hack</option></primary></indexterm>
+ </term>
+ <listitem>
+ <para>Turn off the "state hack" whereby any lambda with a
+ <literal>State#</literal> token as argument is considered to be
+ single-entry, hence it is considered OK to inline things inside
+ it. This can improve performance of IO and ST monad code, but it
+ runs the risk of reducing sharing.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>-fomit-interface-pragmas</option>
+ <indexterm><primary><option>-fomit-interface-pragmas</option></primary></indexterm>
+ </term>
+ <listitem>
+ <para>Tells GHC to omit all inessential information from the interface file
+ generated for the module being compiled (say M). This means that a module
+ importing M will see only the <emphasis>types</emphasis> of the functions that M exports, but not
+ their unfoldings, strictness info, etc. Hence, for example,
+ no function exported by M will be inlined
+ into an importing module. The benefit is that modules that import M will
+ need to be recompiled less often (only when M's exports change their type,
+ not when they change their implementation).
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>-fignore-interface-pragmas</option>
+ <indexterm><primary><option>-fignore-interface-pragmas</option></primary></indexterm>
+ </term>
+ <listitem>
+ <para>Tells GHC to ignore all inessential information when reading interface files.
+ That is, even if <filename>M.hi</filename> contains unfolding or strictness information
+ for a function, GHC will ignore that information.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
<option>-funbox-strict-fields</option>:
<indexterm><primary><option>-funbox-strict-fields</option></primary></indexterm>
<indexterm><primary>strict constructor fields</primary></indexterm>
<varlistentry>
<term>
- <option>-funfolding-update-in-place<n></option>
+ <option>-funfolding-update-in-place=<replaceable>n</replaceable></option>
<indexterm><primary><option>-funfolding-update-in-place</option></primary></indexterm>
</term>
<listitem>
<varlistentry>
<term>
- <option>-funfolding-creation-threshold<n></option>:
+ <option>-funfolding-creation-threshold=<replaceable>n</replaceable></option>:
<indexterm><primary><option>-funfolding-creation-threshold</option></primary></indexterm>
<indexterm><primary>inlining, controlling</primary></indexterm>
<indexterm><primary>unfolding, controlling</primary></indexterm>
</varlistentry>
<varlistentry>
- <term><option>-funfolding-use-threshold<n></option>:</term>
+ <term><option>-funfolding-use-threshold=<replaceable>n</replaceable></option></term>
<listitem>
<indexterm><primary><option>-funfolding-use-threshold</option></primary></indexterm>
<indexterm><primary>inlining, controlling</primary></indexterm>
projects / ghc-hetmet.git / blobdiff