fix: Remove redundant line in .clang-format #4057
Conversation
Used to be no problem, but after a recent VSCode update, this seems to have been causing errors when asking VSCode to format. No idea why this recently became problematic. Signed-off-by: Larry Gritz <[email protected]>
|
The ci.yml for the clang-format test says: I'm not sure why you would get any different results if also using clang12. I, too, have had (minor) differences in the local formatting versus on GHA. I'm not sure why, but it's usually just a couple lines that I can easily fix up by hand to get it to pass on CI. I think even if we got it to 100% match clang12, say, there would still be the issue of some developers using different versions of clang on their end, so I think we'll always be in the situation where people just have to deal with the occasional difference between their local clang-format and the CI one. Aside: I didn't realize it was so long since I updated the clang-format test that it's using clang 12. Should I bump it up to a more recent version? |
Ah, no strong opinion on that. If this is a good opportunity to align with versions used by other ASWF projects then maybe? OSL seems to use 14, MaterialX looks like 15? Personally I'll have easy access to both 12 and 15 :) |
|
Ha! That was news to me (as the person who set up the tests) that the clang-format checks for OIIO and OSL were using different versions! The versions of clang (and llvm, for OSL) that we support is actually a range, and we try to make sure the build CI covers as much of the range as is practical. But we pick a specific one for the clang-format test (because there's no point checking clang-format for several different versions). It makes sense to me that we should periodically update that so that we're always doing clang-format with whatever is the most recent clang version that we are regularly testing. |
…n#4057) Used to be no problem, but after a recent VSCode update, this seems to have been causing errors when asking VSCode to format. No idea why this recently became problematic. Signed-off-by: Larry Gritz <[email protected]>
…n#4057) Used to be no problem, but after a recent VSCode update, this seems to have been causing errors when asking VSCode to format. No idea why this recently became problematic. Signed-off-by: Larry Gritz <[email protected]> Signed-off-by: Peter Kovář <[email protected]>
Used to be no problem, but after a recent VSCode update, this seems to have been causing errors when asking VSCode to format. No idea why this recently became problematic.