Re: Fw: Re: Re: Re: self-compiling failed
Matthew Fluet <[email protected]>
| Newsgroups | gmane.comp.lang.ml.mlton.devel |
|---|---|
| Message-ID | <[email protected]> |
On Wed, May 19, 2010 at 10:46 PM, Baojian Hua <[email protected]> wrote: >> -----Original E-mail----- >> From: "Matthew Fluet" <[email protected]> >> Sent Time: 2010-5-19 21:51:36 >> To: "Baojian Hua" <[email protected]> >> Cc: mlton <[email protected]> >> Subject: Re: Re: [MLton] self-compiling failed >> >> It is enabled under a SML/NJ build of MLton. From the root of the >> mlton source tree, a "make smlnj-mlton" will build a SML/NJ heap image >> and copy it to build/lib. The build/bin/mlton script will prefer a >> MLton build of MLton over a SML/NJ build of MLton, so be sure to >> remove build/lib/mlton-compile. Because SML/NJ's cutoff recompilation >> is faster than MLton's whole program compilation, this is generally >> the way I work when debugging something like an SSA IL optimization >> pass. > > Thanks. But in building with smlnj, the source "ssa/poly-hash.fun" won't > compile. A close look at the code reveals that changing the line 305 to > > fun fini (hexp: Dexp.t): Dexp.t = hexp > > can shut up the compiler. > > Does this mean a bug in smlnj? It is a known issue with SML/NJ using an overly restrictive context for type inference. But, to keep the sources compatible with SML/NJ, we usually include sufficient type constraints. I guess no one has needed to build with SML/NJ in a while, but I committed a fix (slightly different than your constraint, but accomplishes the same).