Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reorder and remove unused #includes #176

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

kittobi1992
Copy link
Member

@kittobi1992 kittobi1992 commented Dec 22, 2023

This change reorders all includes according to the definition in our new .clang-format file, and removes most of the unused includes.

@kittobi1992 kittobi1992 force-pushed the clang_format_revisited branch 3 times, most recently from 4b36772 to a0fe818 Compare December 22, 2023 12:43
@@ -28,17 +28,16 @@

#include "static_graph.h"

#include <algorithm>

#include "tbb/parallel_reduce.h"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the library includes should stay with <>. Just saw this now. Will do a proper read-through later.

Copy link
Member Author

@kittobi1992 kittobi1992 Dec 22, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nope most of them were included in this style before. Btw, I will not go over all files again. This was the most annoying work I've ever done!!! Meaning this is a eat or die change :-D

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, both are used very inconsistently at the moment. I don't really have a preference, but this PR might be a good opportunity to do it uniformly everywhere

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, they are uniform now 😊

Copy link
Member Author

@kittobi1992 kittobi1992 Dec 22, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

btw. we have to transistion to a include-what-you-use policy, otherwise reordering #include becomes a real pain.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, include-what-you-use definitively makes sense

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, they are uniform now 😊

Are you sure? There still seem to be some TBB includes using <>, though the majority uses""

@N-Maas
Copy link
Collaborator

N-Maas commented Dec 22, 2023

The updated formatting options look good to me

Copy link

codecov bot commented Dec 22, 2023

Codecov Report

Attention: 2 lines in your changes are missing coverage. Please review.

Comparison is base (d784c91) 78.90% compared to head (0528632) 78.87%.

Files Patch % Lines
mt-kahypar/io/hypergraph_factory.cpp 0.00% 1 Missing ⚠️
mt-kahypar/partition/partitioner.cpp 0.00% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #176      +/-   ##
==========================================
- Coverage   78.90%   78.87%   -0.03%     
==========================================
  Files         202      202              
  Lines       19632    19629       -3     
  Branches     8036     8035       -1     
==========================================
- Hits        15490    15483       -7     
- Misses       4142     4146       +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@larsgottesbueren
Copy link
Member

The updated formatting options look good to me

There's a couple options that are only supported starting v17 of clang, which is quite recent (truly latest version is v18). On Arch Linux, v16 is the latest available from the package manager (they're super quick usually), and v17 is available from the user repositories starting just two days ago. Below is a list of the unknown options for me. I'd actually really like to have the SpacesInParens option because that one is quite inconsistent in our code base.

We can put these rules in, but some folks will just not be able to apply them (there's a flag to ignore unknown keys, so the other rules can be applied). Still, if we enforce the code style in a CI, we're cutting off contributions.

mt-kahypar/.clang-format:213:1: warning: unknown key 'RemoveParentheses'
RemoveParentheses: Leave
^~~~~~~~~~~~~~~~~
mt-kahypar/.clang-format:31:1: warning: unknown key 'AlignConsecutiveShortCaseStatements'
AlignConsecutiveShortCaseStatements:
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mt-kahypar/.clang-format:231:1: warning: unknown key 'SpaceBeforeJsonColon'
SpaceBeforeJsonColon: false
^~~~~~~~~~~~~~~~~~~~
mt-kahypar/.clang-format:184:1: warning: unknown key 'KeepEmptyLinesAtEOF'
KeepEmptyLinesAtEOF: false
^~~~~~~~~~~~~~~~~~~
mt-kahypar/.clang-format:252:1: warning: unknown key 'SpacesInParens'
SpacesInParens: Never
^~~~~~~~~~~~~~
mt-kahypar/.clang-format:253:1: warning: unknown key 'SpacesInParensOptions'
SpacesInParensOptions:
^~~~~~~~~~~~~~~~~~~~~
mt-kahypar/.clang-format:266:1: warning: unknown key 'VerilogBreakBetweenInstancePorts'
VerilogBreakBetweenInstancePorts: true

@larsgottesbueren
Copy link
Member

Weirdly enough...The SpacesInParens option is warned about as unknown but it is being applied.

The updated formatting options look good to me

There's a couple options that are only supported starting v17 of clang, which is quite recent (truly latest version is v18). On Arch Linux, v16 is the latest available from the package manager (they're super quick usually), and v17 is available from the user repositories starting just two days ago. Below is a list of the unknown options for me. I'd actually really like to have the SpacesInParens option because that one is quite inconsistent in our code base.

We can put these rules in, but some folks will just not be able to apply them (there's a flag to ignore unknown keys, so the other rules can be applied). Still, if we enforce the code style in a CI, we're cutting off contributions.

mt-kahypar/.clang-format:213:1: warning: unknown key 'RemoveParentheses' RemoveParentheses: Leave ^~~~~~~~~~~~~~~~~ mt-kahypar/.clang-format:31:1: warning: unknown key 'AlignConsecutiveShortCaseStatements' AlignConsecutiveShortCaseStatements: ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ mt-kahypar/.clang-format:231:1: warning: unknown key 'SpaceBeforeJsonColon' SpaceBeforeJsonColon: false ^~~~~~~~~~~~~~~~~~~~ mt-kahypar/.clang-format:184:1: warning: unknown key 'KeepEmptyLinesAtEOF' KeepEmptyLinesAtEOF: false ^~~~~~~~~~~~~~~~~~~ mt-kahypar/.clang-format:252:1: warning: unknown key 'SpacesInParens' SpacesInParens: Never ^~~~~~~~~~~~~~ mt-kahypar/.clang-format:253:1: warning: unknown key 'SpacesInParensOptions' SpacesInParensOptions: ^~~~~~~~~~~~~~~~~~~~~ mt-kahypar/.clang-format:266:1: warning: unknown key 'VerilogBreakBetweenInstancePorts' VerilogBreakBetweenInstancePorts: true

@N-Maas
Copy link
Collaborator

N-Maas commented Dec 22, 2023

Installation of the newer version worked for me via the script on https://apt.llvm.org/llvm.sh (Ubuntu). But yeah, its definitively a hurdle for contributors

There's a couple options that are only supported starting v17 of clang, which is quite recent (truly latest version is v18). On Arch Linux, v16 is the latest available from the package manager (they're super quick usually), and v17 is available from the user repositories starting just two days ago. Below is a list of the unknown options for me. I'd actually really like to have the SpacesInParens option because that one is quite inconsistent in our code base.

We can put these rules in, but some folks will just not be able to apply them (there's a flag to ignore unknown keys, so the other rules can be applied). Still, if we enforce the code style in a CI, we're cutting off contributions.

mt-kahypar/.clang-format:213:1: warning: unknown key 'RemoveParentheses' RemoveParentheses: Leave ^~~~~~~~~~~~~~~~~ mt-kahypar/.clang-format:31:1: warning: unknown key 'AlignConsecutiveShortCaseStatements' AlignConsecutiveShortCaseStatements: ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ mt-kahypar/.clang-format:231:1: warning: unknown key 'SpaceBeforeJsonColon' SpaceBeforeJsonColon: false ^~~~~~~~~~~~~~~~~~~~ mt-kahypar/.clang-format:184:1: warning: unknown key 'KeepEmptyLinesAtEOF' KeepEmptyLinesAtEOF: false ^~~~~~~~~~~~~~~~~~~ mt-kahypar/.clang-format:252:1: warning: unknown key 'SpacesInParens' SpacesInParens: Never ^~~~~~~~~~~~~~ mt-kahypar/.clang-format:253:1: warning: unknown key 'SpacesInParensOptions' SpacesInParensOptions: ^~~~~~~~~~~~~~~~~~~~~ mt-kahypar/.clang-format:266:1: warning: unknown key 'VerilogBreakBetweenInstancePorts' VerilogBreakBetweenInstancePorts: true

@larsgottesbueren
Copy link
Member

Thanks for the pointer -- The AUR also has v17. And I agree, the hurdle is a bit too high. Thoughts on adding a github action that will format the code-base pre-merge?

Installation of the newer version worked for me via the script on https://apt.llvm.org/llvm.sh (Ubuntu). But yeah, its definitively a hurdle for contributors

@N-Maas
Copy link
Collaborator

N-Maas commented Dec 22, 2023

Thoughts on adding a github action that will format the code-base pre-merge?

That's probably the best option until version 17 is more widely available

@kittobi1992
Copy link
Member Author

kittobi1992 commented Dec 22, 2023

I do not understand why the hurdle is too high. Contributors do not have to care about formatting unless they want to push something to master. CI tells them that their code is not formatted correctly. They run a script (that will be in our repo) that installs clang-format-17, and then a script that runs the formatter. More active contributor can also install clang-format-17 via the script, and then integrate it into their IDE.

@larsgottesbueren
Copy link
Member

How would a generic clang-format install work -- keeping in mind not everyone uses apt (Debian/Ubuntu).

If we let the CI do the formatting and let it do a commit, we can bypass this issue. See the following link for a snippet how to trigger formatting and auto-commit for a pull request. https://mskelton.medium.com/auto-formatting-code-using-prettier-and-github-actions-ed458f58b7df

I do not understand why the hurdle is too high. Contributors do not have to care about formatting unless they want to push something to master. CI tells them that their code is not formatted correctly. They run a script (that will be in our repo) that installs clang-format-17, and then a script that runs the formatter. More active contributor can also install clang-format-17 via the script, and then integrate it into their IDE.

@kittobi1992
Copy link
Member Author

The CI should be not responsible for formatting since there are some rare cases where formatting can break a build.

Users on Ubuntu can use the installation script. Mac users are already on v17, and Windows, well... 😀

@larsgottesbueren
Copy link
Member

The CI should be not responsible for formatting since there are some rare cases where formatting can break a build.

Users on Ubuntu can use the installation script. Mac users are already on v17, and Windows, well... 😀

Arch Linux is on v16 -- not as bleeding edge as they like to claim. Other distros -- who knows...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants