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

Try to remove SuppressWarnings("GuardedBy") #6578

Open
ejona86 opened this issue Dec 30, 2019 · 2 comments · May be fixed by #11620
Open

Try to remove SuppressWarnings("GuardedBy") #6578

ejona86 opened this issue Dec 30, 2019 · 2 comments · May be fixed by #11620
Milestone

Comments

@ejona86
Copy link
Member

ejona86 commented Dec 30, 2019

#6566 introduced suppressions to allow being compatible with newer versions of Error Prone. But we should spend some time to see if we could tweak the code so that the suppressions would be unnecessary.

If we can't remove them or if it would make the code worse, we can leave them as-is and close this issue.

@ejona86 ejona86 added this to the Next milestone Dec 30, 2019
dapengzhang0 pushed a commit that referenced this issue Dec 30, 2019
This supports releasing a new version of GuardedBy which finds more mistakes than it used to.

Filed #6578 to try to clean up the suppressions.
rickwebiii pushed a commit to rickwebiii/grpc-java that referenced this issue Aug 5, 2020
This supports releasing a new version of GuardedBy which finds more mistakes than it used to.

Filed grpc#6578 to try to clean up the suppressions.
dapengzhang0 pushed a commit that referenced this issue Aug 17, 2020
This supports releasing a new version of GuardedBy which finds more mistakes than it used to.

Filed #6578 to try to clean up the suppressions.

Co-authored-by: Graeme Morgan <[email protected]>
dfawley pushed a commit to dfawley/grpc-java that referenced this issue Jan 15, 2021
This supports releasing a new version of GuardedBy which finds more mistakes than it used to.

Filed grpc#6578 to try to clean up the suppressions.
@vinodhabib
Copy link
Contributor

Started Analysis and going through details.

@kannanjgithub
Copy link
Contributor

This comment for example, says

// TODO(b/145386688): This access should be guarded by 'stream.transportState().lock'; instead
// found: 'this.lock'

Why should it be guarded instead by stream.transportState().lock? What was the change in behavior that CL/282908895 introduced in ErrorProne? At least the above usage seems like would make the code worse if we don't guard it on this.lock that it does today. @ejona86

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

Successfully merging a pull request may close this issue.

3 participants