-Wdelete-non-abstract-non-virtual-dtor was split into two groups back into https://reviews.llvm.org/D56405. but this change has not backported to llvm-toolset-7, which in turn packages Clang/LLVM 5.x.
to avoid the unknown warning options warning messages from the compiler when compiling the tree on el7, we need to check for the existence of this warning option before using it.
in this change,
check for the existence of the "-Wdelete-non-abstract-non-virtual-dtor", before disabling it.
only apply this option on C++ source files. as strictly speaking, this option only applies to C++.
We thank you for helping improve Pipy. In order to ease the reviewing process, we invite you to read the guidelines and ask you to consider the following points before submitting a PR:
We prefer to discuss the underlying issue prior to discussing the code. Therefore, we kindly ask you to refer to an existing issue, or an existing discussion in a public space with members of the Core Team. In few cases, we acknowledge that this might not be necessary, for instance when refactoring code or small bug fixes. In this case, the PR must include the same information an issue would have: a clear explanation of the issue, reproducible code, etc.
Focus the PR to the referred issue, and restraint from adding unrelated changes/additions. We do welcome another PR if you fixed another issue.
If your change is big, consider breaking it into several smaller PRs. In general, the smaller the change, the quicker we can review it.
-Wdelete-non-abstract-non-virtual-dtor was split into two groups back into https://reviews.llvm.org/D56405. but this change has not backported to llvm-toolset-7, which in turn packages Clang/LLVM 5.x.
to avoid the unknown warning options warning messages from the compiler when compiling the tree on el7, we need to check for the existence of this warning option before using it.
in this change,
Signed-off-by: Kefu Chai tchaikov@gmail.com
We thank you for helping improve Pipy. In order to ease the reviewing process, we invite you to read the guidelines and ask you to consider the following points before submitting a PR:
We prefer to discuss the underlying issue prior to discussing the code. Therefore, we kindly ask you to refer to an existing issue, or an existing discussion in a public space with members of the Core Team. In few cases, we acknowledge that this might not be necessary, for instance when refactoring code or small bug fixes. In this case, the PR must include the same information an issue would have: a clear explanation of the issue, reproducible code, etc.
Focus the PR to the referred issue, and restraint from adding unrelated changes/additions. We do welcome another PR if you fixed another issue.
If your change is big, consider breaking it into several smaller PRs. In general, the smaller the change, the quicker we can review it.