We have a new policy in place making links to private resources something we try to avoid in source and test files. Normally, we'd organically switch to the new policy rather than make a sweeping change across a project. However, Clang is in a somewhat special circumstance currently: recently, I've had several new contributors run into rdar links around test code which their patch was changing the behavior of. This turns out to be a surprisingly bad experience, especially for newer folks, for a handful of reasons: not understanding what the link is and feeling intimidated by it, wondering whether their changes are actually breaking something important to a downstream in some way, having to hunt down strangers not involved with the patch to impose on them for help, accidental pressure from asking for potentially private IP to be made public, etc. Because folks run into these links entirely by chance (through fixing bugs or working on new features), there's not really a set of problematic links to focus on -- all of the links have basically the same potential for causing these problems. As a result, this is an omnibus patch to remove all such links. This was not a mechanical change; it was done by manually searching for rdar, radar, radr, and other variants to find all the various problematic links. From there, I tried to retain or reword the surrounding comments so that we would lose as little context as possible. However, because most links were just a plain link with no supporting context, the majority of the changes are simple removals. Differential Review: https://reviews.llvm.org/D158071
This reverts commit d618f1c3b12effd0c2bdb7d02108d3551f389d3d. This commit wasn't reviewed ahead of time and significant concerns were raised immediately after it landed. According to our developer policy this warrants immediate revert of the commit. https://llvm.org/docs/DeveloperPolicy.html#patch-reversion-policy Differential Revision: https://reviews.llvm.org/D155509
This removes links to rdar, which is an internal bug tracker that the community doesn't have visibility into. See further discussion at: https://discourse.llvm.org/t/code-review-reminder-about-links-in-code-commit-messages/71847
Clang already supports the pragma prefixed by "GCC" or "clang". MSVC has more recently added support for the pragma, but without any prefix; see https://devblogs.microsoft.com/cppblog/broken-warnings-theory/#external-headers Differential revision: https://reviews.llvm.org/D104770
The system_header pragma (from GCC) is implemented using line notes in the source manager. However, a line note's line number specifies the number not for the current line, but for the next line. This was making all line numbers appear off by one after the pragma. Reported by Andy Gibbs, uncovered during r179677. llvm-svn: 179709
llvm-svn: 166280
Passing -verify to clang without -cc1 or -Xclang silently passes (with a printed warning, but lit doesn't care about that). This change adds -cc1 or, as is necessary in one case, -Xclang to fix this so that these tests are actually verifying as intended. I'd like to change the driver so this kind of mistake could not be made, but I'm not entirely sure how. Further, since the driver only warns about unknown flags in general, we could have similar bugs with a misspellings of arguments that would be nice to find. llvm-svn: 154776
llvm-svn: 131882
header. Getting it in the wrong order generated incorrect line markers in -E mode. In the testcase from PR9861 we used to generate: # 1 "test.c" 2 # 1 "./foobar.h" 1 # 0 "./foobar.h" # 0 "./foobar.h" 3 # 2 "test.c" 2 now we properly produce: # 1 "test.c" 2 # 1 "./foobar.h" 1 # 1 "./foobar.h" 3 # 2 "test.c" 2 This fixes PR9861. llvm-svn: 131871
clang ' or ' clang -cc1 ' or ' clang-cc ' in test lines (by substituting them to garbage). llvm-svn: 91460