Fix issues which make jison / jison-lex / ... tests fail when run under istanbul/nyc code coverage #32
Assignees
Labels
Comments
Closed
GerHobbelt
added a commit
that referenced
this issue
Dec 22, 2017
…st for jison-lex issue zaach/jison-lex#23 waiting; turned on to (minimally) improve test coverage. Also updated Makefile(s) to truly collect all coverage data when running `make test-nyc`: had seen the `nyc` commandline help, but the hint about `--clean` hadn't landed until I read https://gist.github.com/rundef/22545366591d73330a48b8948fa060a7#gistcomment-1856708
GerHobbelt
added a commit
that referenced
this issue
Dec 22, 2017
…code components exported into generated parsers and/or lexers WILL NOT carry any undesirable code coverage or other code injection/rewriting/etc. artifacts: the code should be exported to the generated parser/lexer codebase as-is, without running the chance that another outside process (compressor/rewriter) modifies the code in unexpected ways). This should also help to reduce the troubles with #7 . Note: now `actionInclude` section uses the same code extraction logic as any action code chunk, hence now also supports arrow functions, when you happen to have specified one of those via the API.
GerHobbelt
added a commit
that referenced
this issue
Dec 23, 2017
… the generated parser when you produce a 'debug level' parser. (Bug found once we got the debug-mode examples subjected to code coverage analysis: without this fix those runs would crash/fail/b0rkb0rkb0rk.
|
Related matter: gotwarlost/istanbul#856 |
GerHobbelt
added a commit
that referenced
this issue
Dec 25, 2017
…anbul` environment. This also takes care of gotwarlost/istanbul#856 until it's fixed in the mainline there. - fix: when both JSON5 and JISON input modes barf a hairball, assume the most important error is the JISON one (show that one first!), while it MAY be a JSON5 format error that triggered it (show that one last!). Also check for common JISON errors which are obviously never triggered by any odd JSON5 input format error: when we encounter such an error here, we don't confuse matters and forget about the JSON5 fail as it's irrelevant.
|
Fixed since today's release 0.6.1-215. All tests and examples behave the same when executed the normal way or when run via
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Code instrumentation for coverage analysis causes the generated parsers/lexers/misc code to fail, hence the mocha test suits fail dramatically when run under istanbul/nyc code coverage.
Guess: This is probably related to #7 as this is yet another code rewriting issue with the jison tool itself. Trouble is very probably due to code being stringified, then edited, then fed back into
eval()/new Function()/similar 'live' code generation constructs.Use
https://github.com/gotwarlost/istanbul/blob/master/ignoring-code-for-coverage.md as a hint list too as the jison core should be 'text-rather-than-code' fixed, while unit tests injecting action code as JavaScript functions, etc. can be nudged into cooperation by using the
/* istanbul ignore ... */marker documented in the URL https://github.com/gotwarlost/istanbul/blob/master/ignoring-code-for-coverage.md .The text was updated successfully, but these errors were encountered: