Adds a relaxation option QualifiersMix which will make the check report for cases where parameters refer to the same type if they only differ in qualifiers.
This makes cases, such as the following, not warned about by default, produce a warning.
void* memcpy(void* dst, const void* src, unsigned size) {}The reasoning behind this is that several projects, code styles, and preferences might consider T and const T fundamentally different types. The related C++ Core Guidelines rule itself shows an example where void T*, const void T* is considered a "good solution".
However, unless people meticulously const their local variables, unfortunately, even such a function carry a potential swap:
T* obj = new T; // Not const!!! void* buf = malloc(sizeof(T)); memcpy(obj, buf, sizeof(T)); // ^~~ ^~~ accidental swap here, even though the interface "specified" a const.
Of course, keeping your things const where appropriate results in an error:
const T* obj = new T;
void* buf = malloc(sizeof(T));
memcpy(obj, buf, sizeof(T));
// error: 1st argument ('const T*') loses qualifiersDue to the rationale behind this depending on project-specific guidelines and preferences, the modelling is introduced as a check option. The default value is false, i.e. T* and const T* are considered unmixable, distinct types.
Originally, the implementation of this feature was part of the very first patch related to this check, D69560 (diff 259320). It has been factored out for clarity and to allow more on-point discussion.
Hmm, use of << is a bit novel but not entirely indefensible. I guess my initial inclination is that you're combing this information into the mix data and so an overload of | was what I was sort of expecting to see here (despite it not really being a bitmask operation). These aren't strong opinions, but I'm curious if you have thoughts.