Adds a relaxation option ModelImplicitConversions which will make the check report for cases where parameters refer to types that are implicitly convertible to one another.
Example:
struct IntBox { IntBox(int); operator int(); }; void foo(int i, double d, IntBox ib) {}
Implicit conversions are the last to model in the set of things that are reasons for the possibility of a function being called the wrong way which is not always immediately apparent when looking at the function (signature or call).
Implicit conversions are approximated in both directions between the parameter types, and if there is a bidirectional swap possibility, the report is made. (I.e. void bar(Base*, Derived*) {} is not reported, because a bar(DP, BP) would be a compile error.)
When a "weak" interface is diagnosed and implicit conversions are involved, the user is given a detailed breakdown (TX -> T1 -> T2 -> TB, TB -> TA, etc.) on the types the value goes through during the conversion. User-defined conversion methods are highlighted at the location with a note tag.
Unfortunately, there isn't a sensible way (at least I found none) to ask Sema at "frontend time" whether or not the two parameters could be implicitly converted between one another, as we do not have the Sema instance anymore. Hence, most of this modelling we have to do ourselves, especially for implicit conversions. Luckily, just like the original patch, it's a few lines of juggling the AST per case.
Diagnosing implicit conversions necessarily increases the number of results (both the reported length and the number of functions matched). We found in our evaluation that this increase is roughly 10%. There were a few oddballs like Bitcoin or Protobuf that produced a 20% climb. Naturally, C projects are a lot worse in this regard due to the much more proliferate use of builtin types, making a 20% increase the norm, rather than the exception.
When it comes to showing developers where their type safety is lacking, the possibility of implicit conversions is the single violator. One can argue about the impossibility of making a better design for functions that take an int, int and can't do better (this is what the Filtering patches try to capture and discard from the results). but there is hardly an excuse for an int, bool if someone wants a stronger safety.
For this very reason, the suggested default value for the check option is true, i.e. implicit conversions are considered, checked, and diagnosed.
'chute, I hate merge conflicts...