[PATCH] D9600: Add scan-build python implementation

[Laszlo Nagy via cfe-commits]

rizsotto.mailinglist added inline comments.

================
Comment at: tools/scan-build-py/libear/ear.c:142
@@ +141,3 @@
+#endif
+    if (!initialized)
+        initialized = bear_capture_env_t(&initial_env);
----------------
dcoughlin wrote:
> rizsotto.mailinglist wrote:
> > rizsotto.mailinglist wrote:
> > > to run the full test set
> > > 
> > > > PATH=$(pwd)/bin:$PATH python -m unittest discover
> > > 
> > > to run that specific test
> > > 
> > > > PATH=$(pwd)/bin:$PATH python -m unittest -v tests.functional.cases.test_create_cdb.CompilationDatabaseTest.test_successful_build_on_empty_env
> > > 
> > > to more about run tests
> > > 
> > > https://docs.python.org/2/library/unittest.html
> > my understanding on the `_NSGetEnviron` is, that it shall be used when the library is during the load process. later when the build process calls `execv` the load process is over, and `environ` variable is available. an earlier version of this code had a `get_environ` method, which were either return the `environ` variable or called the `_NSGetEnviron`. then i made this change and the tests were still passing, so i don't see where your issue is coming from. please tell me what kind of test you run against it to find it as problem. would like to add it to the test suite.
> Aaah, I had an ancient libscanbuild in my global site-packages, which seemed to cause `unittest discover` to not work.
> 
> When running the above on your latest patch on a machine without SIP I get.
> 
> ```
> test_successful_build_on_empty_env (tests.functional.cases.test_create_cdb.CompilationDatabaseTest) ... ERROR
> 
> ======================================================================
> ERROR: test_successful_build_on_empty_env (tests.functional.cases.test_create_cdb.CompilationDatabaseTest)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "tests/functional/cases/test_create_cdb.py", line 58, in test_successful_build_on_empty_env
>     'env', '-'] + make)
>   File "tests/functional/cases/__init__.py", line 38, in silent_check_call
>     return subprocess.check_call(cmd, *args, **kwargs)
>   File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 540, in check_call
>     raise CalledProcessError(retcode, cmd)
> CalledProcessError: Command '['intercept-build', '--cdb', '/var/folders/mq/46lsd1kx65v5702dzrkgzdlr0000gn/T/scan-build-test-cKXza1/cdb.json', 'env', '-', 'make', 'SRCDIR=tests/functional/src', 'OBJDIR=/var/folders/mq/46lsd1kx65v5702dzrkgzdlr0000gn/T/scan-build-test-cKXza1', '-f', 'tests/functional/src/build/Makefile', 'CC=clang', 'build_regular']' returned non-zero exit status 2
> 
> ----------------------------------------------------------------------
> Ran 1 test in 0.554s
> 
> FAILED (errors=1)
> ```
> This goes away if you use my suggested *_NSGetEnviron() fix above.
> After applying that fix, all but 6 test past on OS X without SIP. The remaining 6 failures are due to your use of mknod() in tests, which requires superuser privileges on OS X:
> 
> 
> ```
> ======================================================================
> ERROR: test_interposition_cxx_works (tests.functional.cases.test_from_cmd.RunAnalyzerTest)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/Volumes/Data/Clangs/OpenSourceGit/clang/tools/scan-build-py/tests/functional/cases/test_from_cmd.py", line 102, in test_interposition_cxx_works
>     self.compile_empty_source_file(tmpdir, True))
>   File "/Volumes/Data/Clangs/OpenSourceGit/clang/tools/scan-build-py/tests/functional/cases/test_from_cmd.py", line 87, in compile_empty_source_file
>     os.mknod(src_file)
> OSError: [Errno 1] Operation not permitted
> ```
> 
> Is there a more portable way to create an empty file? Perhaps open a file for writing and then closing it?
> 
> 
> With SIP I see different failures:
> 
> ```
> workzilla:scan-build-py dcoughlin$ PATH=$(pwd)/bin:$PATH python -m unittest -v tests.functional.cases.test_create_cdb.CompilationDatabaseTest.test_successful_build_on_empty_env
> test_successful_build_on_empty_env (tests.functional.cases.test_create_cdb.CompilationDatabaseTest) ... FAIL
> 
> ======================================================================
> FAIL: test_successful_build_on_empty_env (tests.functional.cases.test_create_cdb.CompilationDatabaseTest)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "tests/functional/cases/test_create_cdb.py", line 60, in test_successful_build_on_empty_env
>     self.assertEqual(5, self.count_entries(result))
> AssertionError: 5 != 0
> 
> ----------------------------------------------------------------------
> Ran 1 test in 1.069s
> 
> FAILED (failures=1)
> ```
> 
> Running the entire test suite with SIP yields:
> 
> ```
> FFFFF...EEFFE..................FEEF.EE...............................................
> ...
> Ran 85 tests in 15.688s
> 
> FAILED (failures=9, errors=7)
> ```
> I tried changing intercept.py to always use compiler wrappers on Darwin, but some tests were still failing (tests.functional.cases.test_exec_anatomy.ExecAnatomyTest, tests.functional.cases.test_create_cdb.CompilationDatabaseTest). Do you expect these tests to pass with compiler wrappers? Do they pass for you with compiler wrappers? Or is this some Darwin-specific issue?
thanks Devin, these are interesting findings. however i managed to access to an OS X machine today, have no chance to turn on-and-off the SIP (it was most probably off). and it passed all the tests without any change.

> $ uname -v
> Darwin Kernel Version 13.4.0: Wed Mar 18 16:20:14 PDT 2015; root:xnu-2422.115.14~1/RELEASE_X86_64

anyway, i did replaced the `mknod` call. and also implemented a way to call `_NSGetEnviron` rather than access to environment variable. (tests are still passing on this machine.)

and the `ExecAnatomyTest` is about to capture the different `exec` calls by the `libear` library. would not make sense with compiler wrappers.


http://reviews.llvm.org/D9600