[llvm] Clang-format coroutine files ahead of refactoring (PR #95583)

Yuxuan Chen via llvm-commits llvm-commits at lists.llvm.org
Sat Jun 15 08:33:08 PDT 2024


yuxuanchen1997 wrote:

> My thinking was that when moving code running clang-format on the refactoring patches would result in code changes and maybe that is not great to do. 

I usually just run this to format code strictly contained within my patch. 
```
git diff -U0 --no-color HEAD^ | python3 clang/tools/clang-format/clang-format-diff.py -i -p1
```
Many of us prefer to ignore preexisting formatting issues simply because there are too many such changes. There are repo-wide efforts to make things clang-format clean but turned out to be difficult. 

> I am new to working on this so I will follow your advice.

Welcome! I have been working on this for only about half a year. I have also done prior refactoring for `CoroSplit` and `CoroElide`. I agree things aren't in the best shape and the different ABIs can be very confusing and I totally understand the urge to just make things a bit more understandable. 

One thing I noticed during my refactoring: The philosophy differs quite a lot in this space from C++ to Swift. As far as I can tell, the coro stack is not trying to hide Swift semantics, while it's not the case for C++. There are even specific callouts that says, "this is meaningless for C++, but we do it anyway to keep the middle end clean of C++ semantics."

https://github.com/llvm/llvm-project/pull/95583


More information about the llvm-commits mailing list