[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
@@ -0,0 +1 @@ +dos-style-eol.txt MaskRay wrote: missing text=auto eol=crlf ? https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
ldrumm wrote: > There are a bunch of tests that fail if you don't. Yes. Even better than that: this patch just uncovered a [legitimate bug in the C++ AST parser tests for clang > Our instructions tell people they need to disable autocrlf I didn't see that. Shall I remove that instruction now, or after we've merged? > I don't know that this PR is perfect, but IMO it is a huge step in the right > direction to allow Windows contributors to build, test and contribute to LLVM > using the default configurations of the OS and tools. Absolutely. This patch is not a panacea but it enables us to correctly formalize the case where we actually *do* care about line-endings. Before this patch, it was basically incredibly brittle, but now we actually have control for those tests that matter. For things that don't really matter a whole class of irritating paper-cuts go away forever. I understand folks' hesitance around downstream rebases, but since this will go in as two commits, resolving a merge conflict becomes an easy step (I've [given instructions in the commit that will cause conflicts](https://github.com/llvm/llvm-project/pull/86318/commits/0b70d26534ac788741dc412777fa3396f8c1407c)). I've bumped downstream llvm projects through many major releases in my life (llvm v3 through 13), and change-of-method-name has been a much greater source of merge conflicts than whitespace. LLVM's codebase is healthy and clean largely because we give people the ability to making sweeping improvements. In any case, this will be the last time that a downstream will need to resolve major CRLF changes during a bump, so I consider that a long-term win too. https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
llvm-beanz wrote: > I don't know if the pre-commit testing guarantees that. Configuration > settings will permit the files to be checked out in either Unix (`\n`) or > Windows (`\r\n`) line-endings. Today on Windows you basically have to check out LLVM as unix line endings. There are a bunch of tests that fail if you don't. Hopefully this is a step toward fixing that (which is why I'm in favor of this). > If the builders are all configured to run in Unix line endings we lose that > coverage. I suspect the Windows bots are basically all configured that way today. Our instructions tell people they need to disable `autocrlf` (see: https://llvm.org/docs/GettingStarted.html#getting-the-source-code-and-building-llvm), and not disabling it causes problems for users still (see this message from today: https://discord.com/channels/636084430946959380/745925509971705877/1235913415902629958). >While I understand that this change only changes how the LLVM sources are >stored, the issue is that the LLVM sources include the _tests_ directory. >These need to be tested in various manners to ensure that we test how we >handle the different inputs (in clang). One option might be to exclude the >tests directory from the line ending conversion if we cannot verify that we >have tests in both formats. I see two issues with this: 1) because the repo doesn't work with autocrlf today, we actually can't rely on testing on different platforms to provide this coverage. 2) We shouldn't be relying on git settings to get this coverage anyways. We should have tests that require specific line endings, and we should use gitattributes to ensure that we run those tests regardless of the user's git settings. > While, yes, it is possible to get the wrong behaviour currently, if the user > configures git explicitly for a line-ending, I would expect them to be aware > of that. The use of `.gitattributes` means that their defaults are not > necessarily honoured and thus this can catch them by surprise. I think today not only is it possible to get the wrong behavior, if you're developing on Windows Git's default behavior causes the wrong behavior for LLVM. Which often means that contributors (especially new contributors) have no idea that they're doing something wrong. I don't know that this PR is perfect, but IMO it is a huge step in the right direction to allow Windows contributors to build, test and contribute to LLVM using the default configurations of the OS and tools. https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
https://github.com/ldrumm edited https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
ldrumm wrote: Perhaps things have got lost during the discussion, but my this part of my original commit message is perhaps worth re-reading: > In simple terms this means "unless otherwise specified, convert all files > considered "text" files to LF in the project history, but checkout them out > as expected on the local machine. What is "expected on the local machine" is > dependent on configuration and default. > For those files in the repository that do need CRLF endings, I've adopted a > policy of eol=crlf which means that git will store them in history with LF, > but regardless of user config, they'll be checked out in tree with CRLF. https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
ldrumm wrote: > Note, the changes to clang-format-vs should likely all be reverted. .sln is a > Microsoft Visual Studio solution file, as are many of the others Right. .sln is a text file: https://learn.microsoft.com/en-us/visualstudio/extensibility/internals/solution-dot-sln-file?view=vs-2022 > I have no idea whether Visual Studio will be happy with .natvis files having > non-Windows line endings. They have CRLF line endings: https://github.com/llvm/llvm-project/pull/86318/commits/1994c29731fde75f075c0605b79a14667bcfb9ac#diff-618cd5b83d62060ba3d027e314a21ceaf75d36067ff820db126642944145393eR6 https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
ldrumm wrote: > Also, it's a bit funny to have .bat files without CRLF endings given that > they run on Windows They do have CRLF line endings: https://github.com/llvm/llvm-project/pull/86318/commits/1994c29731fde75f075c0605b79a14667bcfb9ac#diff-618cd5b83d62060ba3d027e314a21ceaf75d36067ff820db126642944145393eR3 https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
compnerd wrote: > Also, it's a bit funny to have .bat files without CRLF endings given that > they run on Windows. I'm not sure about the funny bit - but certainly dangerous. I've had cmd misinterpret batch files with LF vs CRLF. https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
https://github.com/AaronBallman commented: I don't want this to be considered a comment which blocks the changes if others feel strongly in favor of them, but I'm not really convinced we should do this. The number of problems this patch will solve is approximately zero but the number of potential issues it will introduce is definitely nonzero. We've already seen one such problem come up during review and I expect there will be more, but also, this makes potential merge conflicts for downstreams (of the potentially frustrating variety because tools don't make line ending merge conflicts easy to spot). It feels like a lot of churn for little benefit, even in the long term. Note, the changes to clang-format-vs should likely all be reverted. .sln is a Microsoft Visual Studio solution file, as are many of the others. Also, it's a bit funny to have .bat files without CRLF endings given that they run on Windows. I have no idea whether Visual Studio will be happy with .natvis files having non-Windows line endings. Realistically, each one of these files needs to be considered individually and that's a tall order for reviewers. https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
compnerd wrote: > changes to `clang/test/CXX/lex/lex.literal/lex.string/p4.cpp` should be > reverted (it's a CRLF related test) This is the type of problems that I am concerned about. We certainly have some tests which are line-ending sensitive, and each test should be audited before we make such a change. https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
compnerd wrote: > @compnerd I just realised I didn't respond to your concern. Apologies. > > > I think that the concern that I have is that do we have sufficient testing > > for supporting line-ending dependent behaviour in the compiler? > > For the first part: I don't know that it matters, since this patch changes > how the LLVM source code is stored, but not how its parsers operate. In any > case, we run parser testing on LF and CRLF systems since the precommit > testing runs on Linux, and Win32 at least. In addition, and there are several > tests dedicated to line ending, so I think we should be good there. Happy to > tend to this and fix anything I've missed if someone lets me know something > is broken after we merge. I don't know if the pre-commit testing guarantees that. Configuration settings will permit the files to be checked out in either Unix (`\n`) or Windows (`\r\n`) line-endings. If the builders are all configured to run in Unix line endings we lose that coverage. While I understand that this change only changes how the LLVM sources are stored, the issue is that the LLVM sources include the _tests_ directory. These need to be tested in various manners to ensure that we test how we handle the different inputs (in clang). One option might be to exclude the tests directory from the line ending conversion if we cannot verify that we have tests in both formats. > As for the second part > > > Additionally, do we have sufficient documentation for others to figure out > > how to ensure that git does not munge the line endings if they are > > introducing a test which is dependent on it? In such a case, how do we > > ensure that they are aware that the SCM will do so without actually > > checking the post-commit state with a hex editor? > > I don't think we do, but also this patch doesn't really change the problem > since right now basically _anything_ can happen due to local configuration > overrides (`~/.gitconfig`). I'll add a comment to the testing infrastructure > page to be mindful of how line endings are storedand link to the > `.gitattributes` documentation. Does that sound enough? I think that the documentation should be good. While, yes, it is possible to get the wrong behaviour currently, if the user configures git explicitly for a line-ending, I would expect them to be aware of that. The use of `.gitattributes` means that their defaults are not necessarily honoured and thus this can catch them by surprise. https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
cor3ntin wrote: changes to `clang/test/CXX/lex/lex.literal/lex.string/p4.cpp` should be reverted (it's a CRLF related test) https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
ldrumm wrote: > I'll add a comment to the testing infrastructure page to be mindful of how > line endings are storedand link to the .gitattributes documentation. Does > that sound enough? Added [here](https://github.com/llvm/llvm-project/blob/1994c29731fde75f075c0605b79a14667bcfb9ac/llvm/docs/TestingGuide.rst?plain=1#L363) https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
ldrumm wrote: @compnerd I just realised I didn't respond to your concern. Apologies. > I think that the concern that I have is that do we have sufficient testing > for supporting line-ending dependent behaviour in the compiler? For the first part: I don't know that it matters, since this patch changes how the LLVM source code is stored, but not how its parsers operate. In any case, we run parser testing on LF and CRLF systems since the precommit testing runs on Linux, and Win32 at least. In addition, and there are several tests dedicated to line ending, so I think we should be good there. Happy to tend to this and fix anything I've missed if someone lets me know something is broken after we merge. As for the second part >Additionally, do we have sufficient documentation for others to figure out how >to ensure that git does not munge the line endings if they are introducing a >test which is dependent on it? In such a case, how do we ensure that they are >aware that the SCM will do so without actually checking the post-commit state >with a hex editor? I don't think we do, but also this patch doesn't really change the problem since right now basically *anything* can happen due to local configuration overrides (`~/.gitconfig`). I'll add a comment to the testing infrastructure page to be mindful of how line endings are storedand link to the `.gitattributes` documentation. Does that sound enough? https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
https://github.com/llvm-beanz approved this pull request. I'm happy with this approach. We can adjust and iteratively address issues if any appear. https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
ldrumm wrote: I've added the natvis changes and added a couple of clangd test exceptions. For the sanity of pending reviewers, and to make rebasing this trivial I've split this into two commits: the gitattributes changes, followed by the `--renormalize` fixup. For downstreams, I'm considering keeping this as two separate commits (rather than a fixup) so that merge conflicts can be resolved the same way. Anyone have opinions on this? https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
compnerd wrote: Philosophically, I agree with this change. Enshrining the information about the line endings into the SCM tool makes sense. I think that the concern that I have is that do we have sufficient testing for supporting line-ending dependent behaviour in the compiler? Additionally, do we have sufficient documentation for others to figure out how to ensure that git does not munge the line endings if they are introducing a test which is dependent on it? In such a case, how do we ensure that they are aware that the SCM will do so without actually checking the post-commit state with a hex editor? https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
llvm-beanz wrote: > I'm a bit confused. Are you saying that as I've expressed it, `autocrlf=true` > won't work correctly? I _think_ you're saying you're in favour of this patch > _in principal_, but I need to fix the mixed line endings case? Sorry for being unclear. I meant to express that I'm so strongly in favor of what you're accomplishing here that I don't want any of my feedback to stand in the way. https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
llvm-beanz wrote: > This ^ seems a bit problematic to me, though (where the contents of the repo > isn't representative of the bits we want - but perhaps it's schrodinger's > line endings & it doesn't matter if it's always checked out as crlf - though > if we one day converted to another source control system, would that be a > problem? are there some things that examine the underlying/"real" repo > contents?) - what would be the cost to using `eol=input` as you've done for > the mixed line ending case? below \= The argument I would have in favor of an explicit value rather than `eol=input` is that it at least gives us a source of truth in the `.gitattributes` as to what type of line ending the file is supposed to have. I don't have a strong feeling one way or another. I just want `autocrlf=true` to work reliably on all platforms. https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
llvm-beanz wrote: > I am not saying this isn't a problem at all, but how often has anyone done a > one line change and caused a 50k diff, and submitted it without noticing? Way more often than you would hope. I don't have numbers but if you search through the git history for `crlf` or `dos2unix` those phrases hit on a lot of commits (more than just my abolishcrlf.org email address). https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
fmayer wrote: > . The point of this patch is not to lambast developers or interfere with > their local setups; it's to get the line-ending issues out of the way for > good so they can focus on what they do best. Fair enough. I don't think it will fully make them go away for good, as you mentioned "[...] except for specific cases like .bat files or tests for parsers that need to accept such sequences." Something somewhere is bound to work before the transformation, and no longer after. It's possible that that will be more rare, though I would say 100 reverts in all of LLVM history isn't really that much either, all things considered. > And, given what I quoted above, it's not about faith - it's about historical > evidence that this is a problem. I am not saying this isn't a problem at all, but how often has anyone done a one line change and caused a 50k diff, and submitted it without noticing? https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
ldrumm wrote: > > That wish is fine until you start working with others. > > Do we actually have that little faith in developers that we think they will > check in a 50k line diff? depending on their diff settings, or the web interface they use, it may not show until they actually look at a hex editor. The point of this patch is not to lambast developers or interfere with their local setups; it's to get the line-ending issues out of the way for good so they can focus on what they do best. And, given what I quoted above, it's not about faith - it's about historical evidence that this *is* a problem. https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
fmayer wrote: > That wish is fine until you start working with others. Do we actually have that little faith in developers that we think they will check in a 50k line diff? https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
ldrumm wrote: > I don't have a strong opinion, but fundamentally I would prefer if the source > control system stored exactly the files I have in my checkout, not mess with > them in any way. I understand there are practical concerns, but a linter for > unexpected CRLF would maybe be an option? That wish is fine until you start working with others. Then you get 5 line diffs that are somebody changing a single line on *their* system, because they happen to use the opposite system to the last person to check code in. I think the best middle ground here is to say `-text` or `eol=input` for files that *must* be encoded a certain way. As for linters: linters require people to run it, and we still have to encode those rules somewhere - just not gitattributes. As far as I can see this is the lowest overhead and most reliable *pragmatic* option that has the nice property of being fully integrated into the tooling, transparent to end users, and in a known (semi) central location. https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
fmayer wrote: I don't have a strong opinion, but fundamentally I would prefer if the source control system stored exactly the files I have in my checkout, not mess with them in any way. I understand there are practical concerns, but a linter for unexpected CRLF would maybe be an option? https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
dwblaikie wrote: > For those files in the repository that do need CRLF endings, I've adopted a > policy of eol=crlf which means that git will store them in history with LF, > but regardless of user config, they'll be checked out in tree with CRLF. This ^ seems a bit problematic to me, though (where the contents of the repo isn't representative of the bits we want - but perhaps it's schrodinger's line endings & it doesn't matter if it's always checked out as crlf - though if we one day converted to another source control system, would that be a problem? are there some things that examine the underlying/"real" repo contents?) - what would be the cost to using `eol=input` as you've done for the mixed line ending case? below \= > There also appears to be a single test, clang/test/Frontend/rewrite-includes-mixed-eol-crlf.[ch] which needs mixed line endings. This one uses eol=input to preserve it as-is. https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
ldrumm wrote: > Should we come up with an expected filename format that we can use with > gitattributes and rename the existing files rather than just listing each > file that has special needs by itself? Either way, the author has to do or know *something*. I'm not a fan of "magic" like this (notwithstanding the use of file extensions for common win32 formats here), so I'd personally just prefer that the tests that require knowledge of line endings are manually tracked and documented in the gitattributes file. https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
llvm-beanz wrote: Philosophically I agree with this change, but I think some subprojects may need to adopt specific policies about how they handle files that are expected to be specific line endings. Specifically, Clang needs testing that verifies correct behavior on both CRLF and LF files in some cases, as does LLVM's split-file. I did a pass a few years ago fixing a bunch of tests that had hard-specified file offsets in them that broke if you had CRLF line endings, and fixing how the correct line ending type was detected (some of the changes are 13fa17db3a720d149bcd0783856347a4f09cf634, 9d3437fbf3419502351d41ff9e28f06b0c3f06e8, ea836c880abcc74d3983fc35de407d647f0a002d, 1c1b0027e86fab2b0877488abc1625a457ca70b3). Should we come up with an expected filename format that we can use with gitattributes and rename the existing files rather than just listing each file that has special needs by itself? https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
ldrumm wrote: On Mon Mar 25, 2024 at 1:48 PM GMT, Tobias Hieta wrote: > > I think .natvis files should be CRLF (those are used with Visual Studio for > > debug visualizers). > > Agreed, Visual Studio should handle this correctly, but who knows > 路 > Thanks. I'll add a rule and update https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
tru wrote: > I think .natvis files should be CRLF (those are used with Visual Studio for > debug visualizers). Agreed, Visual Studio should handle this correctly, but who knows 路 https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
https://github.com/AaronBallman commented: The changes seem reasonable to me, but there are test failures in `llvm/utils/lit/tests` that could perhaps be related to your changes. I think .natvis files should be CRLF (those are used with Visual Studio for debug visualizers). https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
ldrumm wrote: > LGTM overall, but the CI failure looks real. ``` Failed Tests (3): Clang :: CXX/drs/dr23xx.cpp Clang :: CXX/drs/dr6xx.cpp Clang :: Lexer/raw-string-dlim-invalid.cpp ``` None of these files are in the diffstat, and none of them include any headers. I'm a bit stumped. Is it possible this is spurious? https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
joker-eph wrote: LGTM overall, but the CI failure looks real. https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
rnk wrote: > As a data point, I've been setting core.autocrlf=true on Windows for years. If that's the case, my information is stale, which I accept. > To be clear, this may do nothing on checkout if a user has set a config > option. That addresses my concerns. https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
ldrumm wrote: > So, is there a way to do CRLF -> LF on checkin, but do nothing on checkout? To be clear, this *may* do nothing on checkout if a user has set a config option. The point of the present policy is not to control local preferences as far as the filetype isn't *reqired* to have a specific format; we only control what ends up in history. https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
pogo59 wrote: As a data point, I've been setting `core.autocrlf=true` on Windows for years. I've been trained to make sure _new_ files have LF endings (usually I copy an existing file instead of creating a new file) but both Notepad and the Visual Studio editor are willing to preserve the line-ending mode of the file as they found it. (This was not always true, but is these days.) https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
rnk wrote: I think it makes sense to remove carriage returns on checkin, but I'm not sure it makes sense to add them back on checkout on Windows. Historically, it's been really easy to write LLVM tests that fail when the source is checked out with CRLF. Many Windows developers have noted that LLVM tests fail when using the git config options to accomplish this. So, is there a way to do CRLF -> LF on checkin, but do nothing on checkout? I think all modern editors on Windows can read LF files, it's just that they tend to prefer to write files out in CRLF, and that's the main source of friction. https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
adrian-prantl wrote: While I'm sure this commit will manage to break _something_ unexpectedly, I think this is reasonable to do! Thanks for taking this on. https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff cd8286a667d568c4319b09baa63ba899e3101a19
2dfda2e4b11c7ea0a81dd4dcd43aa426039d1e0a --
clang-tools-extra/test/clang-tidy/checkers/readability/Inputs/duplicate-include/duplicate-include.h
clang-tools-extra/test/clang-tidy/checkers/readability/Inputs/duplicate-include/duplicate-include2.h
clang-tools-extra/test/clang-tidy/checkers/readability/Inputs/duplicate-include/system/sys/types.h
clang-tools-extra/test/clang-tidy/checkers/readability/else-after-return-if-constexpr.cpp
clang/lib/Tooling/DumpTool/ClangSrcLocDump.cpp
clang/test/CXX/dcl.decl/dcl.init/dcl.init.ref/p5-examples.cpp
clang/test/CXX/expr/expr.prim/expr.prim.lambda/p15-star-this-capture.cpp
clang/test/CXX/lex/lex.literal/lex.string/p4.cpp
clang/test/CodeGen/fpconstrained.c clang/test/CodeGen/fpconstrained.cpp
clang/test/CodeGenCXX/attr-x86-no_caller_saved_registers.cpp
clang/test/CodeGenCXX/debug-info-atexit-stub.cpp
clang/test/Driver/ps4-ps5-relax-relocations.c
clang/test/FixIt/fixit-newline-style.c
clang/test/Frontend/rewrite-includes-macros.cpp
clang/test/Frontend/rewrite-includes-mixed-eol-crlf.c
clang/test/Frontend/rewrite-includes-mixed-eol-crlf.h
clang/test/Frontend/system-header-line-directive-ms-lineendings.c
clang/test/Lexer/minimize_source_to_dependency_directives_include.c
clang/test/Lexer/minimize_source_to_dependency_directives_utf8bom.c
clang/test/Preprocessor/macro_vaopt_check.cpp
clang/test/Preprocessor/macro_vaopt_expand.cpp
clang/test/Sema/aarch64-sve-vector-log-ops.c
clang/test/Sema/aarch64-sve-vector-trig-ops.c
clang/test/Sema/incorrect_pure.cpp clang/test/Sema/riscv-rvv-vector-log-ops.c
clang/test/Sema/riscv-rvv-vector-trig-ops.c
clang/test/SemaCXX/attr-non-x86-no_caller_saved_registers.cpp
clang/test/SemaCXX/attr-x86-no_caller_saved_registers.cpp
clang/test/SemaCXX/compound-literal.cpp
clang/test/SemaCXX/cxx23-static-callop-lambda-expression.cpp
clang/test/SemaCXX/vla-ext-diag.cpp clang/test/SemaCXX/warn-redundant-move.cpp
clang/test/SemaCXX/warn-shadow.cpp
clang/test/SemaTemplate/default-expr-arguments-3.cpp
compiler-rt/test/asan/TestCases/Posix/strndup_oob_test2.cpp
lldb/test/Shell/Minidump/Windows/Sigsegv/Inputs/sigsegv.cpp
lldb/test/Shell/SymbolFile/NativePDB/function-types-classes.cpp
lldb/test/Shell/SymbolFile/NativePDB/inline_sites_live.cpp
lldb/test/Shell/SymbolFile/NativePDB/lookup-by-types.cpp
llvm/test/tools/llvm-pdbutil/Inputs/TypeServerTest.cpp
``
View the diff from clang-format here.
``diff
diff --git a/compiler-rt/test/asan/TestCases/Posix/strndup_oob_test2.cpp
b/compiler-rt/test/asan/TestCases/Posix/strndup_oob_test2.cpp
index 5b54c68161..63b4da3502 100644
--- a/compiler-rt/test/asan/TestCases/Posix/strndup_oob_test2.cpp
+++ b/compiler-rt/test/asan/TestCases/Posix/strndup_oob_test2.cpp
@@ -11,7 +11,7 @@
#include
-char kChars[] = { 'f', 'o', 'o' };
+char kChars[] = {'f', 'o', 'o'};
int main(int argc, char **argv) {
char *copy = strndup(kChars, 3);
diff --git a/lldb/test/Shell/Minidump/Windows/Sigsegv/Inputs/sigsegv.cpp
b/lldb/test/Shell/Minidump/Windows/Sigsegv/Inputs/sigsegv.cpp
index d5b96472eb..1519b625fa 100644
--- a/lldb/test/Shell/Minidump/Windows/Sigsegv/Inputs/sigsegv.cpp
+++ b/lldb/test/Shell/Minidump/Windows/Sigsegv/Inputs/sigsegv.cpp
@@ -5,36 +5,28 @@
#include
#else
int main();
-extern "C"
-{
-int _fltused;
-void mainCRTStartup() { main(); }
-void printf(const char*, ...) {}
+extern "C" {
+int _fltused;
+void mainCRTStartup() { main(); }
+void printf(const char *, ...) {}
}
#endif
-void crash(bool crash_self)
-{
-printf("Before...\n");
-if(crash_self)
-{
-printf("Crashing in 3, 2, 1 ...\n");
-*(volatile int*)nullptr = 0;
-}
-printf("After...\n");
+void crash(bool crash_self) {
+ printf("Before...\n");
+ if (crash_self) {
+printf("Crashing in 3, 2, 1 ...\n");
+*(volatile int *)nullptr = 0;
+ }
+ printf("After...\n");
}
-int foo(int x, float y, const char* msg)
-{
-bool flag = x > y;
-if(flag)
-printf("x = %d, y = %f, msg = %s\n", x, y, msg);
-crash(flag);
-return x << 1;
-}
-
-int main()
-{
-foo(10, 3.14, "testing");
+int foo(int x, float y, const char *msg) {
+ bool flag = x > y;
+ if (flag)
+printf("x = %d, y = %f, msg = %s\n", x, y, msg);
+ crash(flag);
+ return x << 1;
}
+int main() { foo(10, 3.14, "testing"); }
``
https://github.com/llvm/llvm-project/pull/86318
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
ldrumm wrote: I'm sure there are lots of people that will want to look at this, so please bring in reviewers at will https://github.com/llvm/llvm-project/pull/86318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
llvmbot wrote: @llvm/pr-subscribers-backend-x86 Author: None (ldrumm) Changes Historically, we've not automatically enforced how git tracks line endings, but there are many, many commits that "undo" unintended CRLFs getting into history. `git log --pretty=oneline --grep=CRLF` shows nearly 100 commits involving reverts of CRLF making its way into the index and then history. As far as I can tell, there are none the other way round except for specific cases like `.bat` files or tests for parsers that need to accept such sequences. Of note, one of the earliest of those listed in that output is: commit 9795860250734e5c2a879546c534e35d9edd5944 Author: NAKAMURA Takumi geek4civic@gmail.com Date: Thu Feb 3 11:41:27 2011 + cmake/*: Add svn:eol-style=native and fix CRLF. llvm-svn: 124793 ...which introduced such a defacto policy for subversion. With old versions of git, it's been a bit of a crapshoot whether enforcing storing line endings in the history will upset checkouts on machines where such line endings are the norm. Indeed many users have enforced that git checks out the working copy according to a global or per-user config via core crlf, or core autocrlf. However, for ~8 years now[1], however, git has supported the ability to "do as the Romans do" on checkout, but internally store subsets of text files with line-endings specified via a system of patterns in the gitattributes file. Since we now have this ability, and we've been specifying attributes for various binary files, I think it makes sense to rid us of all that work converting things "back", and just let git handle the local checkout. Thus the new toplevel policy here is * text=auto In simple terms this means "unless otherwise specified, convert all files considered "text" files to LF in the project history, but checkout them out as expected on the local machine. What is "expected on the local machine" is dependent on configuration and default. For those files in the repository that *do* need CRLF endings, I've adopted a policy of `eol=crlf` which means that git will store them in history with LF, but regardless of user config, they'll be checked out in tree with CRLF. There also appears to be a single test, clang/test/Frontend/rewrite-includes-mixed-eol-crlf.[ch] which needs mixed line endings. This one uses eol=input to preserve it as-is. Finally, existing files have been "corrected" in history via `git add --renormalize .` [1]: git 2.10 was released with fixed support for fine-grained line-ending tracking that respects user-config *and* repo policy. This can be considered the point at which git will respect both the user's local working tree preference *and* the history as specified by the maintainers. See https://github.com/git/git/blob/master/Documentation/RelNotes/2.10.0.txt#L248 for the release note. --- Patch is 1.90 MiB, truncated to 20.00 KiB below, full version: https://github.com/llvm/llvm-project/pull/86318.diff 254 Files Affected: - (modified) .gitattributes (+6) - (added) clang-tools-extra/clangd/test/.gitattributes (+3) - (modified) clang-tools-extra/clangd/test/delimited-input-comment-at-the-end.test (+11-11) - (modified) clang-tools-extra/clangd/test/hover.test (+57-57) - (modified) clang-tools-extra/clangd/test/input-mirror.test (+17-17) - (modified) clang-tools-extra/clangd/test/protocol.test (+113-113) - (modified) clang-tools-extra/clangd/test/spaces-in-delimited-input.test (+13-13) - (modified) clang-tools-extra/clangd/test/too_large.test (+7-7) - (modified) clang-tools-extra/test/clang-tidy/checkers/readability/Inputs/duplicate-include/duplicate-include.h (+15-15) - (modified) clang-tools-extra/test/clang-tidy/checkers/readability/Inputs/duplicate-include/duplicate-include2.h (+1-1) - (modified) clang-tools-extra/test/clang-tidy/checkers/readability/Inputs/duplicate-include/system/sys/types.h (+1-1) - (modified) clang-tools-extra/test/clang-tidy/checkers/readability/else-after-return-if-constexpr.cpp (+22-22) - (modified) clang-tools-extra/test/modularize/Inputs/CompileError/module.modulemap (+10-10) - (modified) clang-tools-extra/test/modularize/Inputs/MissingHeader/module.modulemap (+10-10) - (modified) clang-tools-extra/test/pp-trace/Inputs/module.modulemap (+18-18) - (modified) clang/lib/Tooling/DumpTool/ClangSrcLocDump.cpp (+155-155) - (added) clang/test/.gitattributes (+3) - (modified) clang/test/AST/HLSL/this-reference-template.hlsl (+46-46) - (modified) clang/test/AST/HLSL/this-reference.hlsl (+62-62) - (modified) clang/test/AST/objc-default-ctor-init.mm (+21-21) - (modified) clang/test/CXX/dcl.decl/dcl.init/dcl.init.ref/p5-examples.cpp (+56-56) - (modified) clang/test/CXX/expr/expr.prim/expr.prim.lambda/p15-star-this-capture.cpp (+22-22) - (modified) clang/test/CXX/lex/lex.literal/lex.string/p4.cpp (+17-17) - (modified) clang/test/CodeGen/fpconstrained.c (+25-25) - (modified)
[clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
llvmbot wrote: @llvm/pr-subscribers-clangd @llvm/pr-subscribers-lldb Author: None (ldrumm) Changes Historically, we've not automatically enforced how git tracks line endings, but there are many, many commits that "undo" unintended CRLFs getting into history. `git log --pretty=oneline --grep=CRLF` shows nearly 100 commits involving reverts of CRLF making its way into the index and then history. As far as I can tell, there are none the other way round except for specific cases like `.bat` files or tests for parsers that need to accept such sequences. Of note, one of the earliest of those listed in that output is: commit 9795860250734e5c2a879546c534e35d9edd5944 Author: NAKAMURA Takumi geek4civic@gmail.com Date: Thu Feb 3 11:41:27 2011 + cmake/*: Add svn:eol-style=native and fix CRLF. llvm-svn: 124793 ...which introduced such a defacto policy for subversion. With old versions of git, it's been a bit of a crapshoot whether enforcing storing line endings in the history will upset checkouts on machines where such line endings are the norm. Indeed many users have enforced that git checks out the working copy according to a global or per-user config via core crlf, or core autocrlf. However, for ~8 years now[1], however, git has supported the ability to "do as the Romans do" on checkout, but internally store subsets of text files with line-endings specified via a system of patterns in the gitattributes file. Since we now have this ability, and we've been specifying attributes for various binary files, I think it makes sense to rid us of all that work converting things "back", and just let git handle the local checkout. Thus the new toplevel policy here is * text=auto In simple terms this means "unless otherwise specified, convert all files considered "text" files to LF in the project history, but checkout them out as expected on the local machine. What is "expected on the local machine" is dependent on configuration and default. For those files in the repository that *do* need CRLF endings, I've adopted a policy of `eol=crlf` which means that git will store them in history with LF, but regardless of user config, they'll be checked out in tree with CRLF. There also appears to be a single test, clang/test/Frontend/rewrite-includes-mixed-eol-crlf.[ch] which needs mixed line endings. This one uses eol=input to preserve it as-is. Finally, existing files have been "corrected" in history via `git add --renormalize .` [1]: git 2.10 was released with fixed support for fine-grained line-ending tracking that respects user-config *and* repo policy. This can be considered the point at which git will respect both the user's local working tree preference *and* the history as specified by the maintainers. See https://github.com/git/git/blob/master/Documentation/RelNotes/2.10.0.txt#L248 for the release note. --- Patch is 1.90 MiB, truncated to 20.00 KiB below, full version: https://github.com/llvm/llvm-project/pull/86318.diff 254 Files Affected: - (modified) .gitattributes (+6) - (added) clang-tools-extra/clangd/test/.gitattributes (+3) - (modified) clang-tools-extra/clangd/test/delimited-input-comment-at-the-end.test (+11-11) - (modified) clang-tools-extra/clangd/test/hover.test (+57-57) - (modified) clang-tools-extra/clangd/test/input-mirror.test (+17-17) - (modified) clang-tools-extra/clangd/test/protocol.test (+113-113) - (modified) clang-tools-extra/clangd/test/spaces-in-delimited-input.test (+13-13) - (modified) clang-tools-extra/clangd/test/too_large.test (+7-7) - (modified) clang-tools-extra/test/clang-tidy/checkers/readability/Inputs/duplicate-include/duplicate-include.h (+15-15) - (modified) clang-tools-extra/test/clang-tidy/checkers/readability/Inputs/duplicate-include/duplicate-include2.h (+1-1) - (modified) clang-tools-extra/test/clang-tidy/checkers/readability/Inputs/duplicate-include/system/sys/types.h (+1-1) - (modified) clang-tools-extra/test/clang-tidy/checkers/readability/else-after-return-if-constexpr.cpp (+22-22) - (modified) clang-tools-extra/test/modularize/Inputs/CompileError/module.modulemap (+10-10) - (modified) clang-tools-extra/test/modularize/Inputs/MissingHeader/module.modulemap (+10-10) - (modified) clang-tools-extra/test/pp-trace/Inputs/module.modulemap (+18-18) - (modified) clang/lib/Tooling/DumpTool/ClangSrcLocDump.cpp (+155-155) - (added) clang/test/.gitattributes (+3) - (modified) clang/test/AST/HLSL/this-reference-template.hlsl (+46-46) - (modified) clang/test/AST/HLSL/this-reference.hlsl (+62-62) - (modified) clang/test/AST/objc-default-ctor-init.mm (+21-21) - (modified) clang/test/CXX/dcl.decl/dcl.init/dcl.init.ref/p5-examples.cpp (+56-56) - (modified) clang/test/CXX/expr/expr.prim/expr.prim.lambda/p15-star-this-capture.cpp (+22-22) - (modified) clang/test/CXX/lex/lex.literal/lex.string/p4.cpp (+17-17) - (modified) clang/test/CodeGen/fpconstrained.c (+25-25) - (modified)
