Add Support for clang-format

[Kurt-von-Laven]

"clang-format is located in clang/tools/clang-format and can be used to format C/C++/Java/JavaScript/JSON/Objective-C/Protobuf/C# code." ~ https://clang.llvm.org/docs/ClangFormat.html

Covering 6 different languages and 2 different serialization formats, this linter offers a lot of bang for your buck and seems like a good fit for Mega-Linter. It is one of a very small number of linters present in Super-Linter but missing from Mega-Linter.

The only officially supported installation method is building from source in conjunction with all of LLVM, but unofficially it is also available as a Docker image and Node.js package from Unibeautify.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity.
It will be closed in 14 days if no further activity occurs.
Thank you for your contributions.

If you think this issue should stay open, please remove the O: stale 🤖 label or comment on the issue.

[Kurt-von-Laven]

This still seems worthwhile to me.

[Kurt-von-Laven]

Looks like the bot failed to remove the stale label.

[nvuillam]

Did it manually :)

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity.
It will be closed in 14 days if no further activity occurs.
Thank you for your contributions.

If you think this issue should stay open, please remove the O: stale 🤖 label or comment on the issue.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity.
It will be closed in 14 days if no further activity occurs.
Thank you for your contributions.

If you think this issue should stay open, please remove the O: stale 🤖 label or comment on the issue.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity.
It will be closed in 14 days if no further activity occurs.
Thank you for your contributions.

If you think this issue should stay open, please remove the O: stale 🤖 label or comment on the issue.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity.
It will be closed in 14 days if no further activity occurs.
Thank you for your contributions.

If you think this issue should stay open, please remove the O: stale 🤖 label or comment on the issue.

[daltonv]

I'm interested enough in this issue to try adding this myself, but is there a consensus if megalinter should install clang-format the official way (ie building llvm from source), or is the much simpler but unofficial npm package acceptable?

[nvuillam]

@daltonv thanks for your motivation :)

It's ok to use a package manager if it is more performant ... and maintained, so we are sure to get the latest version ^^

The neighbors of super-linter use another docker image, it can be checked too

[echoix]

Great for your interest! It is one of the linters from super-linter that is missing in Megalinter.

If you're talking about the npm package by angular, https://www.npmjs.com/package/clang-format, it is already outdated and unmaintained ;(

Building llvm + clang + tools from source each time might be a bit too long in GitHub actions runners, we already have workflows that take almost an hour.
Other factor to consider: the size, in the final image and during building. Do you know what are the dependencies for clang-format? Does it need the whole llvm and clang toolchain in order to run?
We are already nearing close to the disk size limits, and cloning the llvm monorepo can be several GB. (Of course shallow clones should be used)

If I remember correctly, clang-format isn't stable between versions, and thus projects using clang-format usually pin a version. How do we handle that? Do we only provide the latest release, and projects must use another solution if they need a specific version?

And lastly, we need to make sure that it works with the muslc in Alpine.

[nvuillam]

I see that there is an apk package containing clang-format, maybe it can work ?

https://pkgs.alpinelinux.org/package/edge/main/ppc64le/clang16-extra-tools

[echoix]

I did a quick test, the dependencies add 532.3 MB

[nvuillam]

it's big, but as clang-format is in super-linter I think it has to be in MegaLinter
But it should be only in full image, not in cupcake on other flavors
Maybe we could create a "c" flavor ?

[daltonv]

I would definitely be in favor of a "c" flavor. I primarily work on embedded C projects, so I'll take a look at all the linters and see what else makes sense to be in that flavor.

[nvuillam]

@daltonv to add a new flavor, you can check this PR -> https://github.com/oxsecurity/megalinter/pull/2778/files#diff-98d0f806abc9af24e6a7c545d3d77e8f9ad57643e27211d7a7b896113e420ed2

Don't be frightened by the number of files, they are almost all generated :)

Basically, update flavor_factory.py, update the descriptors to add the new flavor name , and run bash build.sh :)

[echoix]

A while back in January, I started drafting a list of linters, when I started using cmake-format:

New C/C++/CMake linter ideas

Is your feature request related to a problem? Please describe.
Here is a short list of potential linters to add

• cmakelang (from pip cmakelang)
  • Contains cmake-format: "Can format your listfiles nicely so that they don’t look like crap."
  • Contains cmake-lint: "can check your listfiles for problems"
• Clang-format: In super-linter but not MegaLinter, see Add Support for clang-format #763, Add C++ and CMake linters #478,
• Clang-tidy: Adds more checks and is able to suggest fixes.
• cppcheck (git): Other static analysis, but some different. Might need to check since it is GPL 3 what that implies.

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

[nvuillam]

@echoix indeed more reliable C/C++ linters in MegaLinter could be good ! :)

[daltonv]

So clang-format certainly makes the most sense in the C descriptor file, but then we would be adding clang-format to the cupcake, dotnet, and dotnet web flavors. Either that or removing cpplint from those. Neither of those options sound good to me.

Maybe we have a new clang descriptor? We could even later add clang-tidy in there (it comes with the clang-extra-tools pkg, but I'm not an expert in using clang-tidy yet).

[nvuillam]

We could have a new flavor c_cpp :)