-
Notifications
You must be signed in to change notification settings - Fork 293
enhance_using_directives_267 #387
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
enhance_using_directives_267 #387
Conversation
9c5534b
to
a4f110c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For backwards compatibility, could we recognize existing filters against build/namespaces and build/namespaces_literals?
b21510b
to
f1c7c95
Compare
b2d438e
to
68c551e
Compare
for more information, see https://pre-commit.ci
Filtering by
|
We should only break backwards compatibility on major releases (when I have time—not the near future—we should reorganize the error types anyways), so I think we should keep compatibility with namespace_literals for now. I feel like there's probably a reason that was split out in the first place, probably someone wanting to only filter that out. Also, you don't need to force-push if it squashes into only one commit! GitHub has a "Squash and merge" option. |
The goal of this PR is to figure out how cpplint could support google, cppcoreguidelines, and my org's using-directive policies. The develop branch has one category literals Because of this different categorization, backwards compatibility is difficult. The meaning of build/namespaces is slightly different. For backwards compatibility, I made |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changing the meaning of build/namespace is not ideal but I'm satisfied with the namespace_literal shortcuts.
Description
Enhance the using directives check by adding more granularity to the warnings.
The warnings are split into multiple categories
Possible filter combinations would look like the following
Tests
Unit Tests
Configuration tests
my_test.h
my_test.cc
Tests
Issues
#267