Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2019-09-11T20:39:04+00:00 2019-09-11T20:39:04+00:00 Volodymyr Sapsai vsapsai@apple.com 2019-09-11T20:39:04+00:00 urn:sha1:2f843616849963e8df7a561ce5179ed29a767057 In `DirectoryLookup::LookupFile` parameter `HasBeenMapped` doesn't cover the case when clang finds a file through a header map but doesn't remap the lookup filename because the target path is an absolute path. As a result, -Wnonportable-include-path suppression for header maps introduced in r301592 wasn't triggered. Change parameter `HasBeenMapped` to `IsInHeaderMap` and use parameter `MappedName` to track the filename remapping. This way we can handle both relative and absolute paths in header maps, and account for their specific properties, like filename remapping being a property preserved across lookups in multiple directories. rdar://problem/39516483 Reviewers: dexonsmith, bruno Reviewed By: dexonsmith Subscribers: jkorous, cfe-commits, ributzka Differential Revision: https://reviews.llvm.org/D58094 llvm-svn: 371655 2019-08-09T19:49:14+00:00 Reid Kleckner rnk@google.com 2019-08-09T19:49:14+00:00 urn:sha1:50fcf7285eeb001d751eadac5d001a0e216fd701 This regressed in r368322, and was reported as PR42948 and on the mailing list. The fix is to ignore the specific error code for this case. The problem doesn't seem to reproduce on Windows, where a different error code is used instead. llvm-svn: 368475 2019-05-27T19:15:30+00:00 Volodymyr Sapsai vsapsai@apple.com 2019-05-27T19:15:30+00:00 urn:sha1:e32ff096858578f526b6d05ab97c8f083f2e1834 A filename can be remapped with a header map to point to a framework header and we can find the corresponding framework without the header. But if the original filename doesn't have a remapped framework name, we'll fail to find its location and will dereference a null pointer during diagnostics emission. Fix by tracking remappings better and emit the note only if a framework is found before any of the remappings. rdar://problem/48883447 Reviewers: arphaman, erik.pilkington, jkorous Reviewed By: arphaman Subscribers: dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D61707 llvm-svn: 361779 2019-05-16T21:13:49+00:00 Kristina Brooks notstina@gmail.com 2019-05-16T21:13:49+00:00 urn:sha1:bd9748424165c24280ec1b2ddbe4e7522b15dc96 This relands commit rL360833 which caused issues on Win32 bots due to path handling/normalization differences. Now this uses `sys::path::filename` which should handle additional edge cases on Win32. Original commit: "[Clang][PP] Add the __FILE_NAME__ builtin macro" This patch adds the __FILE_NAME__ macro that expands to the last component of the path, similar to __FILE__ except with a guarantee that only the last path component (without the separator) will be rendered. I intend to follow through with discussion of this with WG14 as a potential inclusion in the C standard or failing that, try to discuss this with GCC developers since this extension is desired by GCC and Clang users/developers alike. Differential Revision: https://reviews.llvm.org/D61756 llvm-svn: 360938 2019-05-16T03:30:08+00:00 Kristina Brooks notstina@gmail.com 2019-05-16T03:30:08+00:00 urn:sha1:9d65624bf6577ad597d80cf4dd9d9aa8d65dec61 This reverts "r360833: [Clang][PP] Add the __FILE_NAME__ builtin macro." The tests are failing on Windows bots, reverting the patchset until I can work out why. llvm-svn: 360842 2019-05-16T00:52:41+00:00 Kristina Brooks notstina@gmail.com 2019-05-16T00:52:41+00:00 urn:sha1:3acc1d1be329d9f6e363c34c455fec86e0c4935c This patch adds the `__FILE_NAME__` macro that expands to the last component of the path, similar to `__FILE__` except with a guarantee that only the last path component (without the separator) will be rendered. I intend to follow through with discussion of this with WG14 as a potential inclusion in the C standard or failing that, try to discuss this with GCC developers since this extension is desired by GCC and Clang users/developers alike. Differential Revision: https://reviews.llvm.org/D61756 llvm-svn: 360833 2019-03-21T20:42:13+00:00 Richard Smith richard-llvm@metafoo.co.uk 2019-03-21T20:42:13+00:00 urn:sha1:6d69fec64516de1e64882aa4452f544c7b890357 in the include path. Instead of making the incorrect claim that the included file has an absolute path, describe the actual problem: the including file was found either by absolute path, or relative to such a file, or relative to the primary source file. llvm-svn: 356712 2018-07-25T19:16:26+00:00 Volodymyr Sapsai vsapsai@apple.com 2018-07-25T19:16:26+00:00 urn:sha1:482070b40a52d1dc1425b8a647686f7949ec2e19 Fixes a problem when we have multiple inclusion cycles and try to enumerate all possible ways to reach the max inclusion depth. rdar://problem/38871876 Reviewers: bruno, rsmith, jkorous, aaron.ballman Reviewed By: bruno, jkorous, aaron.ballman Subscribers: dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D48786 llvm-svn: 337953 2018-06-21T21:45:24+00:00 Bruno Cardoso Lopes bruno.cardoso@gmail.com 2018-06-21T21:45:24+00:00 urn:sha1:dc3f88ad981061a7b4b2872927fceca9ac336453 Header maps are binary files used by Xcode, which are used to map header names or paths to other locations. Clang has support for those since its inception, but there's not a lot of header map testing around. Since it's a binary format, testing becomes pretty much brittle and its hard to even know what's inside if you don't have the appropriate tools. Add a python based tool that allows creating and dumping header maps based on a json description of those. While here, rewrite tests to use the tool and remove the binary files from the tree. This tool was initially written by Daniel Dunbar. Thanks to Stella Stamenova for helping make this work on Windows. Differential Revision: https://reviews.llvm.org/D46485 rdar://problem/39994722 llvm-svn: 335295 2018-06-21T01:23:58+00:00 Bruno Cardoso Lopes bruno.cardoso@gmail.com 2018-06-21T01:23:58+00:00 urn:sha1:1f3cc8c1d3ea8123f53a99c95d4780fbcadf24cb This reverts commit fcfa2dd517ec1a6045a81e8247e346d630a22618. Broke bots: http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/11315 http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/10411/steps/test-check-all/logs/stdio llvm-svn: 335196