Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2019-07-29T17:22:10+00:00 2019-07-29T17:22:10+00:00 Jordan Rupprecht rupprecht@google.com 2019-07-29T17:22:10+00:00 urn:sha1:6a253d378bc05c30b3d9f32fdaf973714de3e99c Summary: This is a bit more explicit, and makes it possible to build LLDB without varying the -I lines per-directory. (The latter is useful because many build systems only allow this to be configured per-library, and LLDB is insufficiently layered to be split into multiple libraries on stricter build systems). (My comment on D65185 has some more context) Reviewers: JDevlieghere, labath, chandlerc, jdoerfert Reviewed By: labath Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65397 Patch by Sam McCall! llvm-svn: 367241 2019-07-29T16:41:30+00:00 Jonas Devlieghere jonas@devlieghere.com 2019-07-29T16:41:30+00:00 urn:sha1:a8ea595509f33834091fb9e3234a373f83d709a8 Right now our Properties.inc only generates the initializer for the options list but not the array declaration boilerplate around it. As the array definition is identical for all arrays, we might as well also let the Properties.inc generate it alongside the initializers. Unfortunately we cannot do the same for enums, as there's this magic ePropertyExperimental, which needs to come at the end to be interpreted correctly. Hopefully we can get rid of this in the future and do the same for the property enums. Differential revision: https://reviews.llvm.org/D65353 llvm-svn: 367238 2019-07-25T21:36:37+00:00 Jonas Devlieghere jonas@devlieghere.com 2019-07-25T21:36:37+00:00 urn:sha1:971f9ca612f22d251631f6b7dcc5efd8324bc0f2 Property definitions are currently defined in a PropertyDefinition array and have a corresponding enum to index in this array. Unfortunately this is quite error prone. Indeed, just today we found an incorrect merge where a discrepancy between the order of the enum values and their definition caused the test suite to fail spectacularly. Tablegen can streamline the process of generating the property definition table while at the same time guaranteeing that the enums stay in sync. That's exactly what this patch does. It adds a new tablegen file for the properties, building on top of the infrastructure that Raphael added recently for the command options. It also introduces two new tablegen backends: one for the property definitions and one for their corresponding enums. It might be worth mentioning that I generated most of the tablegen definitions from the existing property definitions, by adding a dump method to the struct. This seems both more efficient and less error prone that copying everything over by hand. Only Enum properties needed manual fixup for the EnumValues and DefaultEnumValue fields. Differential revision: https://reviews.llvm.org/D65185 llvm-svn: 367058 2019-07-24T17:56:10+00:00 Jonas Devlieghere jonas@devlieghere.com 2019-07-24T17:56:10+00:00 urn:sha1:63e5fb76ecfed3434252868d8cf07d676f979f2f This patch replaces explicit calls to log::Printf with the new LLDB_LOGF macro. The macro is similar to LLDB_LOG but supports printf-style format strings, instead of formatv-style format strings. So instead of writing: if (log) log->Printf("%s\n", str); You'd write: LLDB_LOG(log, "%s\n", str); This change was done mechanically with the command below. I replaced the spurious if-checks with vim, since I know how to do multi-line replacements with it. find . -type f -name '*.cpp' -exec \ sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" + Differential revision: https://reviews.llvm.org/D65128 llvm-svn: 366936 2019-07-05T17:42:08+00:00 Jonas Devlieghere jonas@devlieghere.com 2019-07-05T17:42:08+00:00 urn:sha1:f39c2e188d811ede3758eb98aa0201c1c8f978a1 Change the interface to return an expected, instead of taking a Status pointer. Differential revision: https://reviews.llvm.org/D64163 llvm-svn: 365226 2019-05-24T00:44:33+00:00 Jonas Devlieghere jonas@devlieghere.com 2019-05-24T00:44:33+00:00 urn:sha1:09ad8c8f73dbc64efada18e7ae2f9b64eb1be215 This change replaces built-in types that are implicitly converted to booleans. Differential revision: https://reviews.llvm.org/D62284 llvm-svn: 361580 2019-05-14T08:55:50+00:00 Fangrui Song maskray@google.com 2019-05-14T08:55:50+00:00 urn:sha1:efe8e7e36d01cfa19b8c405fffc3411c8c74cabf Reviewed By: labath Differential Revision: https://reviews.llvm.org/D61883 llvm-svn: 360654 2019-04-10T20:48:55+00:00 Jonas Devlieghere jonas@devlieghere.com 2019-04-10T20:48:55+00:00 urn:sha1:8b3af63b8993e45b1783853a3fcf6f36bfbed81b A lot of comments in LLDB are surrounded by an ASCII line to delimit the begging and end of the comment. Its use is not really consistent across the code base, sometimes the lines are longer, sometimes they are shorter and sometimes they are omitted. Furthermore, it looks kind of weird with the 80 column limit, where the comment actually extends past the line, but not by much. Furthermore, when /// is used for Doxygen comments, it looks particularly odd. And when // is used, it incorrectly gives the impression that it's actually a Doxygen comment. I assume these lines were added to improve distinguishing between comments and code. However, given that todays editors and IDEs do a great job at highlighting comments, I think it's worth to drop this for the sake of consistency. The alternative is fixing all the inconsistencies, which would create a lot more churn. Differential revision: https://reviews.llvm.org/D60508 llvm-svn: 358135 2019-03-06T18:44:27+00:00 Zachary Turner zturner@google.com 2019-03-06T18:44:27+00:00 urn:sha1:a313ec11fc65237498ded287ca53325b7f66a17c llvm-svn: 355531 2019-02-27T21:42:10+00:00 Zachary Turner zturner@google.com 2019-02-27T21:42:10+00:00 urn:sha1:80552918a925ac5ee3419760fdd0c66163e56964 Given that we have a target named Symbols, one wonders why a file named Symbols.cpp is not in this target. To be clear, the functions exposed from this file are really focused on *locating* a symbol file on a given host, which is where the ambiguity comes in. However, it makes more sense conceptually to be in the Symbols target. While some of the specific places to search for symbol files might change depending on the Host, this is not inherently true in the same way that, for example, "accessing the file system" or "starting threads" is fundamentally dependent on the Host. PDBs, for example, recently became a reality on non-Windows platforms, and it's theoretically possible that DSYMs could become a thing on non MacOSX platforms (maybe in a remote debugging scenario). Other types of symbol files, such as DWO, DWP, etc have never been tied to any Host platform anyway. After this patch, there is only one remaining dependency from Host to Target. Differential Revision: https://reviews.llvm.org/D58730 llvm-svn: 355032