How to handle code involving unboxed tuples about cabal-doctest HOT 6 CLOSED

If we specify other-extensions: UnboxedTuples, than cabal-doctest can detect that.

Alternatively, is there a reason not to use -fobject-code always?

from cabal-doctest.

If we specify other-extensions: UnboxedTuples, than cabal-doctest can detect that.

Ah, interesting idea.

Alternatively, is there a reason not to use -fobject-code always?

I don't think we'd want to do this, since we'd be significantly increasing the time it takes for doctest to process each file, since it now has to compile each one. And in the end, doctest would (IIRC) still run the tests themselves in interpreted mode, so I don't think you'd even get any performance benefits from using object code.

from cabal-doctest.

I see, slowing doctest is quite bad, they are slow to begin with.

I can take a look on structs tomorrow.

from cabal-doctest.

I think we have to use -fobject-code in this case, as we can't construct 'foo' from ghci, no?

from cabal-doctest.

This is how I've had to work around this in the past anyways. We're asking doctest to build in a very different manner to support a feature that isn't available to the bytecode compiler. It seems reasonable to have to ask.

from cabal-doctest.

I think we have to use -fobject-code in this case, as we can't construct 'foo' from ghci, no?

Certainly. The question is: what is the best way to inform cabal-doctest that -fobject-code should be used in this specific instance? Currently, we have to hack it in to doctests.hs directly, but we're moving towards being able to specify x-doctest-options: -fobject-code in structs.cabal soon.

from cabal-doctest.