contrib: open a hole in the open().read() ban for open().close()
It turns out open().close() is both fine and something we occasionally
do to verify something can be written. The few cases in the codebase
were getting missed due to a regular expression bug (which I discussed
in my previous change), but since I'm about to fix the bug, I need to
fix the patterns.
Differential Revision: https://phab.mercurial-scm.org/D2864
--- a/contrib/check-code.py Wed Mar 14 15:39:28 2018 -0400
+++ b/contrib/check-code.py Wed Mar 14 15:42:23 2018 -0400
@@ -319,9 +319,9 @@
"use util.readfile() instead"),
(r'[\s\(](open|file)\([^)]*\)\.write\(',
"use util.writefile() instead"),
- (r'^[\s\(]*(open(er)?|file)\([^)]*\)',
+ (r'^[\s\(]*(open(er)?|file)\([^)]*\)(?!\.close\(\))',
"always assign an opened file to a variable, and close it afterwards"),
- (r'[\s\(](open|file)\([^)]*\)\.',
+ (r'[\s\(](open|file)\([^)]*\)\.(?!close\(\))',
"always assign an opened file to a variable, and close it afterwards"),
(r'(?i)descend[e]nt', "the proper spelling is descendAnt"),
(r'\.debug\(\_', "don't mark debug messages for translation"),