Comments (10)
I can workaround this via
cabal repl -w doctest --ghc-options=-Wno-type-defaults
Actually, I cannot confirm that --ghc-options=-Wno-type-defaults
has any effect. I was under the impression that this was the workaround, but actually I get both false positives and false negatives. So, this flag is likely irrelevant.
It must be other effects that fix this sporadic problem. Like running for a second time, building again, whatever. I cannot see the pattern.
from doctest.
A reliable workaround is to add this to the .cabal
file:
ghc-options: -Wno-type-defaults
from doctest.
@andreasabel I think we want to make sure that --ghc-options=-Wno-type-defaults
works as expected, or at the very least understand what exactly is happening here.
Can you check if --ghc-options=-Wno-type-defaults
takes effect for a regular cabal repl
ghci session?
If no, we want to figure out how to convince cabal
to pass GHC options to cabal repl
.
If yes, we want to understand what's going on Doctest's side, likely in ghci-wrapper
.
from doctest.
To try to simulate this in GHCI/cabal repl I'd need to know what doctest
makes out of a doctest expression e
. The error above mentions a print it
...
from doctest.
I tried to construct a little reproducer:
doctest-issue.cabal
:
cabal-version: 2.0
name: doctest-issue
version: 0.0.0
build-type: Simple
library
hs-source-dirs: src
exposed-modules: OverloadedStrings
default-language: Haskell2010
default-extensions: OverloadedStrings
ghc-options: -Wall
build-depends: base
src/OverloadedStrings.hs
module OverloadedStrings (foo) where
-- | Fooking do noothing.
--
-- >>> foo ["a", "b", "c"]
-- ["a","b","c"]
--
foo :: Ord a => [a] -> [a]
foo xs = xs
However, in this case the type-defaults
warning can be successfully suppressed:
$ cabal build && cabal repl -w doctest --ghc-options=-Wno-type-defaults
... (ok)
I shrank too much, it seems.
from doctest.
I have played 2 hours now with this issue and I found that cabal build/repl
are stateful in an awful way so that I can reach both states where:
- I see no error despite not giving
--ghc-options=-Wno-type-defaults
. - I see the error despite giving
--ghc-options=-Wno-type-defaults
.
All this depends on the history of (at least) the following actions.
a. cabal clean
(silent transition)
b. cabal build
(silent transition)
c. cabal repl -w doctest
(accept or reject depending on whether tests pass)
d. cabal repl -w doctest --ghc-options=-Wno-type-defaults
(accept or reject)
Research question:
- Document an action sequence that ends in state 2.
- Figure out the language (action sequences that lead to accept), and if exists finite state automaton generating this language.
- If you are not successful in question 2, try complete the picture by new actions. (Maybe by interrupting actions c/d.)
from doctest.
This sounds frightening. If you can come up with a repro then I guess we need a Cabal issue for this (a repro without -w doctest
would be ideal, but even if the repro requires -w doctest
it's still something that shouldn't happen).
from doctest.
Here is an example run, organized in three lines:
- Action (
b
,c
,d
). - Doctest result:
-
(didn't run),o
(success),x
(failure). - Whether result is pathological:
-
(expected),1
(bad 1., see above),2
(bad 2.).
bcddbdcdbdcdccbccd
-xxx-ooo-ooooo-xxx
--22--1---1-11---2
This random sequence supports the following thesis:
If the first
cabal repl -w doctest
aftercabal build
comes with--ghc-options=-Wno-type-defaults
, then the doctest will succeed and continue to succeed, no matter if this option is included in subsequent invokations ofcabal repl -w doctest
or not. Symmetrically, if the option is omitted on the first doctest invokation, the test will fail and continue to fail, whether this option is passed later or not.
from doctest.
Wer lesen kann, ist im Vorteil. RTFD:
cabal repl TARGET
loads all of the modules of the target into GHCi as interpreted bytecode. In addition to cabal build’s flags, it additionally takes the--repl-options
and--repl-no-load
flags.To avoid ghci specific flags from triggering unneeded global rebuilds these flags are now stripped from the internal configuration. As a result
--ghc-options
will no longer (reliably) work to pass flags to ghci (or other repls). Instead, you should use the new--repl-options
flag to specify these options to the invoked repl.
Ok, this explains the erratic behavior. (What I do not understand, though, is why cabal repl
happily takes --ghc-options
on the command line, and then does WHAT EXACTLY with them?)
@sol wrote:
@andreasabel I think we want to make sure that
--ghc-options=-Wno-type-defaults
works as expected, or at the very least understand what exactly is happening here.
So, answer is, it does not work, but --repl-options=-Wno-type-defaults
seems to work as expected.
(This it the first time I see --repl-options
, but frankly, I never use cabal repl
.)
from doctest.
Reported cabal repl --ghc-options
upstream:
from doctest.
Related Issues (20)
- Weird test failure due to type error with GHC 9.2.1 HOT 5
- "not in scope" errors when running with GHC 9 + stack test; redux HOT 20
- Disable test without changing rendering HOT 1
- 0.20.0 doesn't build on ghc 9.4.2 HOT 6
- Invalid platform constants HOT 2
- Error related to OverloadedLists not reported as such HOT 3
- Build failure on GHC 9.6 HOT 1
- How to pass `--fast` when going via `cabal repl`? HOT 1
- `doctest` in multi-GHC setting HOT 6
- One test fails with GHC 9.6.1 HOT 1
- Ci: ubuntu-18.04 will be discontinued soon HOT 1
- Can I focus doctest on a particular function in a module or can I exclude functions from being tested? HOT 2
- GHC 9.4.5, doctest 0.22.0 `$setup import …` does only work with `cabal repl --with-ghc=doctest` HOT 1
- `cabal test` integration (GHC 9.4.5) HOT 7
- cabal repl --enable-multi-repl --with-ghc=doctest fails with "unrecognized option `-unit'" HOT 4
- Unexpected Kind errors when building tests
- Build failure with GHC 9.6 HOT 1
- Could we have multiline expectations? HOT 1
- Support GHC 9.10 HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from doctest.