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

DAOS-623 client: allow variable declaration in loop #15428

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

Conversation

jxiong
Copy link

@jxiong jxiong commented Oct 30, 2024

This PR tries to enable variable declaration in loop from C99 standard. This will not make coding easier, but will also make the code less error-prone by limiting the scope of looping variables.

The Linux kernel adopts C99 for this exact same reason.

NB: I only updated the variable in the for loops. It seems like this file hasn't been changed since new clang-format is used. Maybe I picked a wrong file to start with ;-)

Before requesting gatekeeper:

  • Two review approvals and any prior change requests have been resolved.
  • Testing is complete and all tests passed or there is a reason documented in the PR why it should be force landed and forced-landing tag is set.
  • Features: (or Test-tag*) commit pragma was used or there is a reason documented that there are no appropriate tags for this PR.
  • Commit messages follows the guidelines outlined here.
  • Any tests skipped by the ticket being addressed have been run and passed in the PR.

Gatekeeper:

  • You are the appropriate gatekeeper to be landing the patch.
  • The PR has 2 reviews by people familiar with the code, including appropriate owners.
  • Githooks were used. If not, request that user install them and check copyright dates.
  • Checkpatch issues are resolved. Pay particular attention to ones that will show up on future PRs.
  • All builds have passed. Check non-required builds for any new compiler warnings.
  • Sufficient testing is done. Check feature pragmas and test tags and that tests skipped for the ticket are run and now pass with the changes.
  • If applicable, the PR has addressed any potential version compatibility issues.
  • Check the target branch. If it is master branch, should the PR go to a feature branch? If it is a release branch, does it have merge approval in the JIRA ticket.
  • Extra checks if forced landing is requested
    • Review comments are sufficiently resolved, particularly by prior reviewers that requested changes.
    • No new NLT or valgrind warnings. Check the classic view.
    • Quick-build or Quick-functional is not used.
  • Fix the commit message upon landing. Check the standard here. Edit it to create a single commit. If necessary, ask submitter for a new summary.

@jxiong jxiong requested review from a team as code owners October 30, 2024 01:08
@jxiong jxiong marked this pull request as draft October 30, 2024 01:08
Copy link

github-actions bot commented Oct 30, 2024

Ticket title is 'Generic ticket for minor code cleanup and improvement'
Status is 'Resolved'
Labels: 'request_for_2.6.2'
https://daosio.atlassian.net/browse/DAOS-623

wangshilong
wangshilong previously approved these changes Oct 30, 2024
Copy link
Contributor

@wangshilong wangshilong left a comment

Choose a reason for hiding this comment

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

It might be better to have a ticket number, I thought there is a MISC ticket for such PRs. @jolivier23

@jolivier23
Copy link
Contributor

It might be better to have a ticket number, I thought there is a MISC ticket for such PRs. @jolivier23

there is DAOS-623

jolivier23
jolivier23 previously approved these changes Oct 30, 2024
Copy link
Contributor

@jolivier23 jolivier23 left a comment

Choose a reason for hiding this comment

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

it would appear you don't need to change anything in clang-format. It must not care with current settings.

@jxiong
Copy link
Author

jxiong commented Oct 30, 2024

It might be better to have a ticket number, I thought there is a MISC ticket for such PRs. @jolivier23

@wangshilong This PR is just for reference purpose so that I can collect community's feedback. I will certainly add a daos ticket once we decide to move it forward. Thanks for calling it out.

@jxiong jxiong changed the title [NO TICKET] format: allow variable declaration in loop DAOS-623 format: allow variable declaration in loop Oct 30, 2024
@jxiong jxiong self-assigned this Oct 30, 2024
@jxiong jxiong marked this pull request as ready for review October 30, 2024 20:16
@jxiong jxiong changed the title DAOS-623 format: allow variable declaration in loop DAOS-623 client: allow variable declaration in loop Oct 30, 2024
@jxiong jxiong dismissed stale reviews from jolivier23 and wangshilong via 5c8a986 November 4, 2024 17:56
ashleypittman
ashleypittman previously approved these changes Nov 5, 2024
jolivier23
jolivier23 previously approved these changes Nov 5, 2024
@jxiong
Copy link
Author

jxiong commented Nov 7, 2024

@jolivier23 I don;t think this CI test (continuous-integration/jenkins/pr-head) would pass, I have tried 3 times but no luck. What would be your suggestion for the next step?

@ashleypittman
Copy link
Contributor

@jolivier23 I don;t think this CI test (continuous-integration/jenkins/pr-head) would pass, I have tried 3 times but no luck. What would be your suggestion for the next step?

There was a network issue when the build was starting, I've retriggerd it.

@jxiong jxiong requested a review from a team November 8, 2024 17:16
@daltonbohning
Copy link
Contributor

Ideally, we should get a review from @daos-stack/client-api-owners before merging.

Copy link
Contributor

@mchaarawi mchaarawi left a comment

Choose a reason for hiding this comment

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

i do not get the purpose of doing these changes on just this file. this screws up git blame.
we probably have many other files that do not have clang format and i will request we don't do such changes for now unless we make a discussion to address this everywhere.


rc = dc_obj_get_grp_size(oh, &grp_size);
if (rc)
D_GOTO(out, rc);

for (i = 0; i < layout->ol_nr; i++) {
for (uint32_t i = 0; i < layout->ol_nr; i++) {
Copy link
Contributor

Choose a reason for hiding this comment

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

this is not our coding style

Copy link
Contributor

Choose a reason for hiding this comment

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

We don't have much code that looks like this but keeping the scope of variables as small as possible is something that is explicitly stated in our style guide and it's something that's generally considered best-practice across the industry. I know I've fixed at least one bug in our codebase where a loop variable was misused later in the function.

Changing existing code is laborious and time consuming, plus there are the issues it causes with glt blame and patches across branches etc but I that doesn't change the fact this style would be safer, more concise and preferable overall.

Copy link
Contributor

Choose a reason for hiding this comment

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

i do not disagree. but we are not going to go on and change every part of the code to do this.
we are just going to cause more disruptions to ongoing prs, feature branches that is not going to give that much gain.

so i will approve the change for this file, because i know there is not much work going on in the object api area. @jxiong but please refrain from pushing such a change more broadly before discussing this more in developer channels and/or gatekeeping channels.

Copy link
Contributor

Choose a reason for hiding this comment

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

@mchaarawi are you in the community slack channel? My understanding is this PR was created to support a discussion there.

Copy link
Contributor

Choose a reason for hiding this comment

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

I am. this is not a community question though. this is developer specific topic.

@jxiong
Copy link
Author

jxiong commented Nov 12, 2024

i do not get the purpose of doing these changes on just this file. this screws up git blame. we probably have many other files that do not have clang format and i will request we don't do such changes for now unless we make a discussion to address this everywhere.

I agree with you that we should not make PRs for this change only. This is just to make an example of such change. The PR description gives a clearer explanation on this. The goal is sort of to announce that this is a preferred way of defining loop variables.

@mchaarawi
Copy link
Contributor

mchaarawi commented Nov 12, 2024

i do not get the purpose of doing these changes on just this file. this screws up git blame. we probably have many other files that do not have clang format and i will request we don't do such changes for now unless we make a discussion to address this everywhere.

I agree with you that we should not make PRs for this change only. This is just to make an example of such change. The PR description gives a clearer explanation on this. The goal is sort of to announce that this is a preferred way of defining loop variables.

i think step 1 would be to revert all the clang format changes in the file. you should not format code that you did not touch. I am not ready to loose git blame information on all files :-)
We use git blame to assign issues in some situations.

for the loop variable declaration, this is not something we discussed or adopted, so we cannot force it on everyone without a discussion in gatekeeping at least.

@jxiong
Copy link
Author

jxiong commented Nov 12, 2024

i do not get the purpose of doing these changes on just this file. this screws up git blame. we probably have many other files that do not have clang format and i will request we don't do such changes for now unless we make a discussion to address this everywhere.

I agree with you that we should not make PRs for this change only. This is just to make an example of such change. The PR description gives a clearer explanation on this. The goal is sort of to announce that this is a preferred way of defining loop variables.

i think step 1 would be to revert all the clang format changes in the file. you should not format code that you did not touch. I am not ready to loose git blame information on all files :-) We use git blame to assign issues in some situations.

for the loop variable declaration, this is not something we discussed or adopted, so we cannot force it on everyone without a discussion in gatekeeping at least.

That's absolutely reasonable. I don't have any background on this topic but it seems like we have a clang-format in place but it's not actually in use. (I have dev config that clang-format will be invoked automatically on file save).

I will revert the clang-format change and resubmit.

Change-Id: I8c6b78f95b3737f604ac87b4d16636202074c47b
@jxiong jxiong dismissed stale reviews from ashleypittman and jolivier23 via 4bc1807 November 12, 2024 23:47
@daosbuild1
Copy link
Collaborator

Test stage NLT on EL 8.8 completed with status UNSTABLE. https://build.hpdd.intel.com/job/daos-stack/job/daos//view/change-requests/job/PR-15428/6/testReport/

@jxiong
Copy link
Author

jxiong commented Nov 15, 2024

@jolivier23 @ashleypittman can anyone of you please restart the CI for me? Thanks

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

Successfully merging this pull request may close these issues.

7 participants