You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As brought up in #6, doctest-parallel currently errors if it finds a doctest that is part of an internal module. This is usually the right thing to do: it couldn't access the function under test anyway. However, if that particular function is re-exported from an exposed module, it could technically access it. My guess is that this is currently hard-ish to implement, however, it should be easy once https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6224 is merged as we could easily compare names.
For me personally this is not a particularly high-priority issue (hence the enhancement label):
doctest-parallel currently errors in these cases, no tests will be silently ignored.
In almost all cases I consider hiding modules (and symbols) an anti-feature. If users want to use an internal symbol we (library authors) should let them. I'm therefore skeptical of the use of non-exposed modules in the first place.
The text was updated successfully, but these errors were encountered:
As brought up in #6,
doctest-parallel
currently errors if it finds a doctest that is part of an internal module. This is usually the right thing to do: it couldn't access the function under test anyway. However, if that particular function is re-exported from an exposed module, it could technically access it. My guess is that this is currently hard-ish to implement, however, it should be easy once https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6224 is merged as we could easily compare names.For me personally this is not a particularly high-priority issue (hence the
enhancement
label):doctest-parallel
currently errors in these cases, no tests will be silently ignored.The text was updated successfully, but these errors were encountered: