Comment 1 Markus Schorn 2011-05-30 03:28:13 EDT

This is an interesting issue. Let me simplify your example first:

void f(int* p); 
void test() {
  f(x); 
}

In the example the parser has to decide whether the statement 'f(x)' is a declaration- or expression statement. It chooses the declaration statement, because it causes only one problem binding. 

You can make the code compile by changing the declaration of 'f':
typedef int f;
void test() {
  f(&x); 
}

To fix the issue, we'd have to put weights on the problem bindings found during ambiguity resolution. Vaguely there could be rules like that:
* A problem binding nested more deeply is less important
* A failure in the overload-resolution is less important than a failure in the 
  name-lookup

I am not sure whether this is worth the effort, though. 
However, this code is not correct, because the reference is not initialized. We could improve the parser to detect that. But then I can change the example to 

void f(int* p); // compiles with 'typedef int f', instead;
void test() {
  f(x); 
}

Comment 2 Sergey Prigogin 2011-05-30 21:37:32 EDT

(In reply to comment #1)
> To fix the issue, we'd have to put weights on the problem bindings found during
> ambiguity resolution. Vaguely there could be rules like that:
> * A problem binding nested more deeply is less important
> * A failure in the overload-resolution is less important than a failure in the 
>   name-lookup

The minimal number of problem bindings as a target function for ambiguity resolution has always bothered me as something not based on the C++ spec. A more correct approach would be to prefer the code interpretation that pushes the first problem as further down as possible (in declaredBefore sense). The problems that cannot be ordered by declaredBefore could be classified into original and dependent. Dependent problems should not be counted towards the target function for ambiguity resolution.

The latter rule may be hard to implement, so we may have to replace it with the rules you proposed.

> I am not sure whether this is worth the effort, though. 

It may not be critical now, but will become more and more important as we improve Codan diagnostics and quick fixes.

Comment 3 Sergey Prigogin 2014-03-26 13:47:51 EDT

See also related bug 431271.