A year ago I submitted a change to replace AnyError with tests for specific
errors (see https://github.com/elves/elvish/commit/87656c99). This does
something similar for DoesNotCompile. This ensures the test does what
is implied and makes correlating specific unit tests with compilation
errors easier.
This includes a couple of changes to compilation error messages to improve
readability (IMHO) but those are not the primary purpose of this change.
Related #1560
cmp.Diff panics when comparing a struct that has unexported fields and no String
or Equal method, so change some structs to either export all their fields or
have an Equal method.
This fixes#1136.
The `AnyError` placeholder error can cause tests to succeed for errors
other than what was expected. That is, the use of `AnyError` can mask
bugs in a unit test. So replace it with the specific error, or error type,
the test expects to be raised.
This does not remove the anyError structure because it is used in
the TestCase.DoesNotCompile() method. To keep the size of this change
as small as possible I want to defer updating that use to a separate
change. However, remove the public AnyError var so future test writers
don't attempt to use it.
Replaces uses of the deprecated builtin `prclose` and `pwclose` commands
with `file close` in unit tests.
This also fixes one test that was not verifying what it intended due to
it's use of `.Throws(AnyError)` which was matching an Elvish error caused
by invalid command `file:prclose $p`.
* Remove `MatchesRegexp` from eval/vals since it is not part of the
Elvish value protocol.
* Simplify implementation of value matching in `eval/evaltest`.
* Documentation wording tweaks.
This change is a preparation step for refining all *Op types to return Exception
as the error.
Keeping Exception as a struct type will make such a change error-prone, since
a (*Exception)(nil) != error(nil), so if an *Op returns a nil *Exception, it
is not nil if the return value is stored in an error-typed variable.
As with commit #eb2a792 I acknowledge that `golint` recommendations are
controversial and should not automatically be acted on. Nonetheless,
this change fixes legitimate lint issues such as copy/paste cleanups,
style problems I introduced (`i += 1` versus `i++`) or method/var comments
that are not in the preferred form.
