Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generalize strict #1689

Merged
merged 16 commits into from
Oct 14, 2021
Merged

Conversation

ericphanson
Copy link
Contributor

Fixes #1686 by generalizing strict to accept a symbol or vector of symbols. I was going to do just doctest but looking at it, it seemed about as easy to do all of them.

I only found tests with strict for doctests though, but I modified those to try some of the new versions.

@ericphanson
Copy link
Contributor Author

ericphanson commented Aug 30, 2021

What this does:

  • collects all the names we use for errors and puts them in ERROR_NAMES
  • allows strict to be set to a Bool as now, or a Symbol from ERROR_NAMES or a Vector{Symbol} that is a subset of ERROR_NAMES. This allows any middle ground between false and true, by being strict about any subset of the possible errors. This is validated by is_strict_kw, a new utility function.
  • Sets the loglevel when we log errors according to if we are being strict about that error or not, using is_strict, a new utility function
  • Errors at the end of the build if we are strict about any errors that have occurred (or after doctest time if we are strict about doctest and any doctests have failed), using is_strict
  • Adds some unit tests for is_strict and is_strict_kw, and runs some of the doctest tests with various equivalent (for the purpose of doctests) choices of strict.

I am happy with it from my end and am ready for review when you get a chance.

@ericphanson
Copy link
Contributor Author

Bump

@ericphanson
Copy link
Contributor Author

Bump

src/Utilities/Utilities.jl Outdated Show resolved Hide resolved
Copy link
Member

@fredrikekre fredrikekre left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM but would be good to document somewhere what the different options for symbols are.

Co-authored-by: Albin Heimerson <albheim@hotmail.com>
@ericphanson
Copy link
Contributor Author

The list is in the docstring (https://github.com/JuliaDocs/Documenter.jl/pull/1689/files#diff-2c620811ba00ffd5e7b818bdefbab47fe9d7e3e11d046e6fe18e5c01fdff3f0cR227) but maybe you’re saying the meaning of them all should be documented too? That would make sense to me, though I’m not sure where to put it.

@ericphanson
Copy link
Contributor Author

CI failures seem to be pkg server issues. (Especially considering everything passed just before and the only difference was typos in a docstring).

@ericphanson
Copy link
Contributor Author

Bump :). Would love to get this in soon-- I think it would massively increase the usability of doctests if there was an easy way to make them fail the built without also making everything else fatal.

@ericphanson
Copy link
Contributor Author

Bump

@fredrikekre fredrikekre removed the request for review from mortenpi October 14, 2021 09:06
CHANGELOG.md Outdated Show resolved Hide resolved
@fredrikekre fredrikekre merged commit 6d633fb into JuliaDocs:master Oct 14, 2021
@ericphanson ericphanson deleted the eph/flexible_strict branch October 14, 2021 10:27
@ericphanson
Copy link
Contributor Author

awesome, thanks @fredrikekre!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Fail docs build if there are doctest errors
4 participants