Originally reported by Ben Webb (Bitbucket: benmwebb, GitHub: benmwebb)
Let me know if you need a way to reproduce this and I'll see if I can boil it down to a simple example - but right now this is happening for our (pretty large) project.
This is on an x86_64 Fedora 22 box with the Fedora package, under Python 3 (the RPM claims to be python3-coverage-4.0-0.10.b1.fc22.x86_64). Partial stacktrace:
#!shell
File "/usr/lib64/python3.4/site-packages/coverage/control.py", line 1010, in html_report
return reporter.report(morfs)
File "/usr/lib64/python3.4/site-packages/coverage/html.py", line 124, in report
self.report_files(self.html_file, morfs, self.config.html_dir)
File "/usr/lib64/python3.4/site-packages/coverage/report.py", line 83, in report_files
report_fn(fr, self.coverage._analyze(fr))
File "/usr/lib64/python3.4/site-packages/coverage/html.py", line 169, in html_file
this_hash = self.file_hash(source.encode('utf-8'), fr)
File "/usr/lib64/python3.4/site-packages/coverage/html.py", line 160, in file_hash
self.coverage.data.add_to_hash(fr.filename, m)
File "/usr/lib64/python3.4/site-packages/coverage/data.py", line 535, in add_to_hash
hasher.update(sorted(self.arcs(filename)))
TypeError: 'NoneType' object is not iterable
This appears to occur because arcs() is returning None for at least one of the files in my project. The documentation for arcs() says that None is an acceptable return value...
Things work normally again for me if I modify the add_to_hash() function to check for a None return value, and if so, skip the hasher update.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4