Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2020-06-10T12:21:44+00:00 2020-06-10T12:21:44+00:00 Sam McCall sam.mccall@gmail.com 2020-04-07T00:49:51+00:00 urn:sha1:0530e2a811b08f13e8137c29f047ad6bd11967fa Summary: Our previous definition of "top-level" was too informal, and didn't allow for overlapping macros that each directly produce expanded tokens. See D77507 for previous discussion. Fixes http://bugs.llvm.org/show_bug.cgi?id=45428 Reviewers: kadircet, vabridgers Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D77615 (cherry picked from commit d66afd6dde542dc373f87e07fe764c071fe20d76) 2020-06-10T12:21:44+00:00 Sam McCall sam.mccall@gmail.com 2020-04-07T00:46:16+00:00 urn:sha1:41c5efc3f2f22475bf3290309c90e84713511711 Summary: The motivation here is fixing https://bugs.llvm.org/show_bug.cgi?id=45428, see D77507. The fundamental problem is that a "top-level" expansion wasn't precisely defined. Repairing this concept means that TokenBuffer's "top-level expansion" may not correspond to a single macro expansion. Example: ``` M(2); // expands to 1+2 ``` The expansions overlap, but neither expansion alone yields all the tokens. We need a TokenBuffer::Mapping that corresponds to their union. This is fairly easy to fix in CollectPPExpansions, but the current design of TokenCollector::Builder needs a fix too as it relies on the macro's expansion range rather than the captured expansion bounds. This fix is hard to make due to the way code is reused within Builder. And honestly, I found that code pretty hard to reason about too. The new approach doesn't use the expansion range, but only the expansion location: it assumes an expansion is the contiguous set of expanded tokens with the same expansion location, which seems like a reasonable formalization of the "top-level" notion. And hopefully the control flow is easier to follow too, it's considerably shorter even with more documentation. Reviewers: kadircet Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D77614 (cherry picked from commit ec0b9908952a9f4a19c3eb92ba0fc01cffcb8614) 2020-02-26T08:28:39+00:00 Kadir Cetinkaya kadircet@google.com 2020-02-26T08:03:03+00:00 urn:sha1:0fe369ad5ff69394b9076b1a679502c3993488d1 Summary: Fixes https://github.com/clangd/clangd/issues/279. We were removing the color options but not the preceeding -Xclang which causes errors since the -Xclang would now apply to the next option in the list of options. Now, when removing a color option, we check if there was a preceeding -Xclang and remove it as well. Patch By @DaanDeMeyer ! Reviewers: sammccall, kadircet Reviewed By: sammccall Subscribers: ilya-biryukov, usaxena95 Differential Revision: https://reviews.llvm.org/D75019 (cherry picked from commit da236f235028c82c2f0e00eea1f6f9c689bcae4a) 2020-01-14T21:52:20+00:00 Michael Liao michael.hliao@gmail.com 2020-01-14T21:29:47+00:00 urn:sha1:a3490e3e3d38d502179329f76138d96c5b2bab88 2020-01-14T16:00:33+00:00 Ilya Biryukov ibiryukov@google.com 2020-01-14T11:34:00+00:00 urn:sha1:013c07f697886649b068cd97127e528b4fe7c03e And add a corresponding test. Only nodes inside the TranslationUnit subtree can be marked as original, computeReplacements() relies on this. 2020-01-14T15:41:09+00:00 Ilya Biryukov ibiryukov@google.com 2020-01-14T15:27:06+00:00 urn:sha1:07a41018e9d27f67f7b4295eb7e00e0345c0aacf This was an oversight in the original patch. Also add corresponding tests. 2020-01-14T15:31:08+00:00 Ilya Biryukov ibiryukov@google.com 2020-01-14T15:07:11+00:00 urn:sha1:3b929fe7763570fc1d4a4691a53257a4a0b7760e Add checks for some structural invariants when building and mutating the syntax trees. Fix a bug failing the invariants after mutations: the parent of nodes added into the tree was null. 2020-01-03T11:33:11+00:00 Ilya Biryukov ibiryukov@google.com 2020-01-03T11:05:14+00:00 urn:sha1:04f627f6b9aeda924a83e75d281ab27a546d3515 When they are free-standing, e.g. `struct X;` or `struct X {};`. Although this complicates the common case (of free-standing class declarations), this ensures the less common case (e.g. `struct X {} a;`) are handled uniformly and produce similar syntax trees. 2020-01-01T19:01:37+00:00 Mark de Wever koraq@xs4all.nl 2020-01-01T16:23:21+00:00 urn:sha1:8dc7b982b4556c243e0502e6e230bdd53ddd65ff This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall. Differential Revision: https://reviews.llvm.org/D71857 2019-12-20T13:36:21+00:00 Dmitri Gribenko gribozavr@gmail.com 2019-12-20T13:35:10+00:00 urn:sha1:73f423e739bcb9bee7b73f05d4bcd50782013a8c This change fixes a warning on the ppc64be buildbot.