=?utf-8?q?Balázs_Kéri?= <balazs.k...@ericsson.com>,
=?utf-8?q?Balázs_Kéri?= <balazs.k...@ericsson.com>,
=?utf-8?q?Balázs_Kéri?= <balazs.k...@ericsson.com>,
=?utf-8?q?Balázs_Kéri?= <balazs.k...@ericsson.com>,
=?utf-8?q?Balázs_Kéri?= <balazs.k...@ericsson.com>,
=?utf-8?q?Balázs_Kéri?= <balazs.k...@ericsson.com>,
=?utf-8?q?Balázs_Kéri?= <balazs.k...@ericsson.com>,
=?utf-8?q?Balázs_Kéri?= <balazs.k...@ericsson.com>,
=?utf-8?q?Balázs_Kéri?= <balazs.k...@ericsson.com>,
=?utf-8?q?Balázs_Kéri?= <balazs.k...@ericsson.com>,
=?utf-8?q?Balázs_Kéri?= <balazs.k...@ericsson.com>
Message-ID:
In-Reply-To: <llvm.org/llvm/llvm-project/pull/140...@github.com>
================
@@ -0,0 +1,87 @@
+.. title:: clang-tidy - misc-override-with-different-visibility
+
+misc-override-with-different-visibility
+=======================================
+
+Finds virtual function overrides with different visibility than the function
+in the base class. This includes for example if a virtual function declared as
+``private`` is overridden and declared as ``public`` in a subclass. The
detected
+change is the modification of visibility resulting from keywords ``public``,
+``protected``, ``private`` at overridden virtual functions. The check applies
to
+any normal virtual function and optionally to destructors or operators. Use of
+the ``using`` keyword is not considered as visibility change by this check.
+
+
+.. code-block:: c++
+
+ class A {
+ public:
+ virtual void f_pub();
+ private:
+ virtual void f_priv();
+ };
+
+ class B: public A {
+ public:
+ void f_priv(); // warning: changed visibility from private to public
+ private:
+ void f_pub(); // warning: changed visibility from public to private
+ };
+
+ class C: private A {
+ // no warning: f_pub becomes private in this case but this is from the
+ // private inheritance
+ };
+
+ class D: private A {
+ public:
+ void f_pub(); // warning: changed visibility from private to public
+ // 'f_pub' would have private access but is forced to be
+ // public
+ };
+
+If the visibility is changed in this way, it can indicate bad design or
+programming error.
+
+If a virtual function is private in a subclass but public in the base class, it
+can still be accessed from a pointer to the subclass if the pointer is
converted
+to the base type. Probably private inheritance can be used instead.
+
+A protected virtual function that is made public in a subclass may have valid
+use cases but similar (not exactly same) effect can be achieved with the
+``using`` keyword.
+
+Options
+-------
+
+.. option:: DisallowedVisibilityChange
+
+ Controls what kind of change to the visibility will be detected by the check.
+ Possible values are `any`, `widening`, `narrowing`. For example the
+ `widening` option will produce warning only if the visibility is changed
+ from more restrictive (``private``) to less restrictive (``public``).
+ Default value is `any`.
+
+.. option:: CheckDestructors
+
+ If turned on, the check does apply to destructors too. Otherwise destructors
----------------
vbvictor wrote:
```suggestion
If `true`, the check does apply to destructors too. Otherwise destructors
```
https://github.com/llvm/llvm-project/pull/140086
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
