ci: disallow some common capitalization mistakes (#2472)

* ci: only annotate linux for now

* style: block some common mistakes

.github/workflows/ci.yml

@@ -12,6 +12,7 @@ on:
 jobs:
   standard:
     strategy:
+      fail-fast: false
       matrix:
         runs-on: [ubuntu-latest, windows-latest, macos-latest]
         arch: [x64]
@@ -103,6 +104,7 @@ jobs:
       run: python -m pip install -r tests/requirements.txt --prefer-binary
 
     - name: Setup annotations
+      if: runner.os == 'Linux'
       run: python -m pip install pytest-github-actions-annotate-failures
 
     - name: Configure C++11 ${{ matrix.args }}

.pre-commit-config.yaml

@@ -36,6 +36,14 @@ repos:
 
 - repo: local
   hooks:
+  - id: disallow-caps
+    name: Disallow improper capitalization
+    language: pygrep
+    entry: PyBind|Numpy|Cmake
+    exclude: .pre-commit-config.yaml
+
+- repo: local
+  hooks:
   - id: check-style
     name: Classic check-style
     language: system

docs/advanced/cast/eigen.rst

@@ -274,7 +274,7 @@ Vectors versus column/row matrices
 
 Eigen and numpy have fundamentally different notions of a vector.  In Eigen, a
 vector is simply a matrix with the number of columns or rows set to 1 at
-compile time (for a column vector or row vector, respectively).  Numpy, in
+compile time (for a column vector or row vector, respectively).  NumPy, in
 contrast, has comparable 2-dimensional 1xN and Nx1 arrays, but *also* has
 1-dimensional arrays of size N.
 

docs/changelog.rst

@@ -628,7 +628,7 @@ v2.2.0 (August 31, 2017)
   in reference cycles.
   `#856 <https://github.com/pybind/pybind11/pull/856>`_.
 
-* Numpy and buffer protocol related improvements:
+* NumPy and buffer protocol related improvements:
 
   1. Support for negative strides in Python buffer objects/numpy arrays. This
      required changing integers from unsigned to signed for the related C++ APIs.
@@ -1359,7 +1359,7 @@ Happy Christmas!
 * Improved support for ``std::shared_ptr<>`` conversions
 * Initial support for ``std::set<>`` conversions
 * Fixed type resolution issue for types defined in a separate plugin module
-* Cmake build system improvements
+* CMake build system improvements
 * Factored out generic functionality to non-templated code (smaller code size)
 * Added a code size / compile time benchmark vs Boost.Python
 * Added an appveyor CI script

docs/faq.rst

@@ -285,7 +285,7 @@ CMake code. Conflicts can arise, however, when using pybind11 in a project that
 Python detection in a system with several Python versions installed.
 
 This difference may cause inconsistencies and errors if *both* mechanisms are used in the same project. Consider the following
-Cmake code executed in a system with Python 2.7 and 3.x installed:
+CMake code executed in a system with Python 2.7 and 3.x installed:
 
 .. code-block:: cmake
 

docs/upgrade.rst

@@ -32,7 +32,7 @@ something. The changes are:
   ``CMAKE_CXX_STANDARD=<number>`` instead, or any other valid CMake CXX or CUDA
   standard selection method, like ``target_compile_features``.
 
-* If you do not request a standard, PyBind11 targets will compile with the
+* If you do not request a standard, pybind11 targets will compile with the
   compiler default, but not less than C++11, instead of forcing C++14 always.
   If you depend on the old behavior, please use ``set(CMAKE_CXX_STANDARD 14)``
   instead.

tests/test_numpy_vectorize.cpp

@@ -37,7 +37,7 @@ TEST_SUBMODULE(numpy_vectorize, m) {
     ));
 
     // test_type_selection
-    // Numpy function which only accepts specific data types
+    // NumPy function which only accepts specific data types
     m.def("selective_func", [](py::array_t<int, py::array::c_style>) { return "Int branch taken."; });
     m.def("selective_func", [](py::array_t<float, py::array::c_style>) { return "Float branch taken."; });
     m.def("selective_func", [](py::array_t<std::complex<float>, py::array::c_style>) { return "Complex float branch taken."; });