forked from cpplint/cpplint
-
Notifications
You must be signed in to change notification settings - Fork 0
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
[pull] develop from cpplint:develop #1
Open
pull
wants to merge
126
commits into
martinzink:develop
Choose a base branch
from
cpplint:develop
base: develop
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In the situation, where one git/svn/hg repository is located inside the directory tree of another, the search incorrectly selects the outer one instead of the inner one.
PiperOrigin-RevId: 480954960
There is no Common Lisp operator named PRINT-UNPRINTABLE-OBJECT. Given the context, it is certain that PRINT-UNREADABLE-OBJECT (www.lispworks.com/documentation/lw51/CLHS/Body/m_pr_unr.htm) was meant instead.
Fix PRINT-UNPRINTABLE-OBJECT
Update ts styleguide with latest google version
PiperOrigin-RevId: 489165518
Go Style Guide
PiperOrigin-RevId: 489255983
Go: Fix a logic error in an example.
s/Vimscript/Vim script/
PiperOrigin-RevId: 489430034
PiperOrigin-RevId: 489956630
Add link to the Go guide from README.md.
PiperOrigin-RevId: 493761232
PiperOrigin-RevId: 497970050
…patch-1 Trivial typofix
Internal Change.
pylint triggered: pylint: Command line or configuration file:1: UserWarning: Specifying exception names in the overgeneral-exceptions option without module name is deprecated and support for it will be removed in pylint 3.0. Use fully qualified name (maybe 'builtins.StandardError' ?) instead. pylint: Command line or configuration file:1: UserWarning: Specifying exception names in the overgeneral-exceptions option without module name is deprecated and support for it will be removed in pylint 3.0. Use fully qualified name (maybe 'builtins.Exception' ?) instead. pylint: Command line or configuration file:1: UserWarning: Specifying exception names in the overgeneral-exceptions option without module name is deprecated and support for it will be removed in pylint 3.0. Use fully qualified name (maybe 'builtins.BaseException' ?) instead. Suggestion works out.
"complex.h" was both a C99 System header and a old legacy C++ System header. These days, it can be expected that the C header is meant, so cpplint should treat it like that.
A chromium sample has been updated to a version that uses C++17 stuff READMEs of samples have been clarified regarding licensing Two licenses have also been updated Our setup.py now includes a BSD classifier for PyPI
Move usage to its own section and provide rudimentary instructions to defuse error caused by external package managers
Add support for specifying a NOLINT in a block of code. The block is started with a NOLINTBEGIN comment which can specify one or more categories. The block is ended with a NOLINTEND comment which clears all categories specified in the BEGIN. Errors are generated if a BEGIN statment occurs in a block, if END is specified without a BEGIN or if END specifies categories This is similar to the clang-tidy NOLINTBEGIN/END feature. Fixes google#31 Fixes #137
Previously, cpplint has complained when a no-argument constructor is marked `explicit`. This is bad for two reasons: 1. As of C++11, converting constructors can be called with any number of arguments including 0. Therefore, this check is wrong. (see https://en.cppreference.com/w/cpp/language/converting_constructor ) 2. Even in pre-C++-11 code, it is good defensive programming practice to mark all constructors `explicit`. Marking a constructor that cannot be a conversion `explicit` has no ill effect, but if someone alters it to be a possible implicit conversion, it defends you against them forgetting to add `explicit`. --------- Co-authored-by: Aaron Liu <[email protected]>
[Mandated by Google](https://google.github.io/styleguide/cppguide.html#Namespace_Formatting) This also shakes up the relevant tests a bit --------- Co-authored-by: Aaron Liu <[email protected]>
Forgot to change a verbosity in a merge! (Yes, this is @aaronliu0130. I will only use this method for really critical situations. Sorry. This is exactly the same as #268.) Co-authored-by: Aaron Liu <[email protected]>
By explicitly specifying the legacy setuptools build backend via pyproject.toml, we ensure that the current directory is visible to the setup.py invocation. Without this, in some environments I observe that pip installing the sdist or a clone of the repo fails because the current directory is not on the PYTHONPATH (for instance, using cpplint as a pre-commit hook fails for me on some Python/pip versions). Note that this is because the setup.py in this repo imports the cpplint module from the current directory, and for this reason it is necessary to specify that the build backend is `setuptools.build_meta:__legacy__`, not just `setuptools.build_meta`.
This PR removes the false positives from `_HEADERS_CONTAINING_TEMPLATES` that come from non `std` namespaces. Users of boost or other namespaces will no longer get false positives. ```c++ // Warn set<int> blah1; std::set<int> blah2; ::std::set<int> blah2; set<int> blah1; std::set<int> blah2; ::std::set<int> blah2; // NO WARN foo.set<int>(); foo->set<int>(); boost::container::set<int> blah3; blah::std::set<int> blah3; my_std::set<int> blah3; my_set<int> blah4; coolset<int> blah5; std::blah<int> blah6; ::set<int> blah7; ```
Add changelog for #273, standardize the changelog's name to all-caps, stop vi favortism, and add some PR guidance to CONTRIBUTING. Co-authored-by: Aaron Liu <[email protected]>
1. Fixes #212 2. else statements that have braces on both sides but have the second-to-last } on a separate line will no longer claim we need braces on both sides 3. Fix single-line if statements being yelled at to split their lines, something contradictory to the style guide 4. Fixes relevant tests, including adding the new "TestLintContains" and "TestLintNotContains" methods. (ik the latter may have a grammar error but who cares, this is consistent with the former's name) 5. Add a todo for "This exception does not apply to multi-keyword statements like if ... else or do ... while." --------- Co-authored-by: Aaron Liu <[email protected]>
The compiler or language server should check these instead. We don't believe that this will result in any false behavior from NestingState. --------- Co-authored-by: Aaron Liu <[email protected]>
To be consistent with other documentation.
Use uint16_t,int32_t,etc instead of uint16,int32,etc as the expected typenames when looking for c-style casts.
Modernized to include more violations that we could potentially detect Combined with cfg-sample Also gitignore vscode stuff now --------- Co-authored-by: Aaron Liu <[email protected]>
While the docs dislike long functions, there's no hard limit. Co-authored-by: RafaelGSS <[email protected]>
Used a `requires` keyword for concept detection, as the `concept` keyword could be a few lines above the opening brace. Not 100% on the regex, so if someone could check it, I would appreciate it.
This is fine for our repo and leads to many innocent PRs being flagged down by Pylint 3.3.0
This also speeds up execution by on average 1.3%. Huh.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )