Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2020-01-13T22:54:57+00:00 2020-01-13T22:54:57+00:00 Alex Langford apl@fb.com 2020-01-13T22:53:05+00:00 urn:sha1:6d57511e0b6f95a369efe7274923a36de3489e7b In the documentation of `include_directories`, it notes that `target_include_directories` is preferred because it affects specific targets intead of propagating include search paths to the entire project. 2020-01-13T19:41:30+00:00 Alex Langford apl@fb.com 2020-01-11T00:10:06+00:00 urn:sha1:2bb154591fab6c1d3a99d63ef03c234f0a363410 No files in lldb-server are including a header from a plugin without the whole path to the header relative to the lldb source directory. There is no need to include the specific directories as a result. 2019-12-13T18:00:59+00:00 Jonas Devlieghere jonas@devlieghere.com 2019-12-12T18:00:45+00:00 urn:sha1:3011d55f725e280fe29a49bd70a2e0157587b17a Rename LLDB_DISABLE_POSIX to LLDB_ENABLE_POSIX and use cmakedefine01 for consistency. 2019-11-18T18:27:27+00:00 Vedant Kumar vsk@apple.com 2019-11-14T22:30:56+00:00 urn:sha1:4624e83ce7b124545b55e45ba13f2d900ed65654 Allow clients of the llvm library to opt-in to one-shot SIGPIPE handling, instead of forcing them to undo llvm's SIGPIPE handler registration (which is brittle). The current behavior is preserved for all llvm-derived tools (except lldb) by means of a default-`true` flag in the InitLLVM constructor. This prevents "IO error" crashes in long-lived processes (lldb is the motivating example) which both a) load llvm as a dynamic library and b) *really* need to ignore SIGPIPE. As llvm signal handlers can be installed when calling into libclang (say, via RemoveFileOnSignal), thereby overriding a previous SIG_IGN for SIGPIPE, there is no clean way to opt-out of "exit-on-SIGPIPE" in the current model. Differential Revision: https://reviews.llvm.org/D70277 2019-10-11T11:47:07+00:00 Martin Storsjo martin@martin.st 2019-10-11T11:47:07+00:00 urn:sha1:807dbee36679a8e43b25c3fcfd38e750fd4e943d This should allow lldb-server to operate on files with non-ascii pathnames. I tried looking around in lldb/tools, and this seemed like the only other tool (other than the main lldb driver itself) that would be used (implicitly) by an end user (which could be working in non-ascii paths). Differential Revision: https://reviews.llvm.org/D68864 llvm-svn: 374537 2019-09-23T12:03:21+00:00 Martin Storsjo martin@martin.st 2019-09-23T12:03:21+00:00 urn:sha1:33d29a60a23e4dbdcb4b1a39571300c66139f6d7 The variable is unused on windows. Differential Revision: https://reviews.llvm.org/D67895 llvm-svn: 372589 2019-09-16T22:55:49+00:00 Jonas Devlieghere jonas@devlieghere.com 2019-09-16T22:55:49+00:00 urn:sha1:3cabfb344b820586bb7c43212340f64246cde8eb llvm-svn: 372044 2019-09-13T22:00:03+00:00 Tim Shen timshen91@gmail.com 2019-09-13T22:00:03+00:00 urn:sha1:573863ea180b7ce73dda4e019ad94fddf2222363 llvm-svn: 371902 2019-09-13T20:08:27+00:00 Jan Korous jkorous@apple.com 2019-09-13T20:08:27+00:00 urn:sha1:f69c91780fbb0e9c0e95f70a079f578efdca0bfa Differential Revision: https://reviews.llvm.org/D67424 llvm-svn: 371890 2019-08-14T22:19:23+00:00 Jonas Devlieghere jonas@devlieghere.com 2019-08-14T22:19:23+00:00 urn:sha1:a8f3ae7c9cefa8296d119f92ca444087cdccf712 Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368933