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

[pull] develop from cpplint:develop #1

Open
wants to merge 126 commits into
base: develop
Choose a base branch
from

Conversation

pull[bot]
Copy link

@pull pull bot commented Jan 30, 2023

See Commits and Changes for more details.


Created by pull[bot]

Can you help keep this open source service alive? 💖 Please sponsor : )

Georg Piewald and others added 23 commits February 4, 2019 18:07
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.
Update ts styleguide with latest google version
PiperOrigin-RevId: 489165518
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
@pull pull bot added the ⤵️ pull label Jan 30, 2023
algonell and others added 6 commits February 2, 2023 11:31
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.
aaronliu0130 and others added 30 commits February 29, 2024 15:00
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
Follow-up to #217, another try to fix #27. This stops IWYU on erring on tokens with namespace prefixes that aren't std.
This change should preserve backward compatibility while preventing false positives for common names in other namespaces.
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
Projects
None yet
Development

Successfully merging this pull request may close these issues.