Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Existing Binding cannot be resolved

The biggest reason that the resolveFunction returns null when it believes the function does not match the parameters is that in the case of unqualified function calls there are additional places to look for more functions.  (This is Argument-dependent lookup, aka Koenig lookup).  The other reason is that (assuming we are right about the parameters not matching) it is actually a compile error.  To return something other than null would be an assumption that we are wrong and have a bug.  I would like to think we are right more often than we are wrong here.

So the bug here is not so much that we aren't returning substr, but more that we don't know what size_type is.  If we correctly recognized size_type as something that can convert an integer to then the method binding will be returned correctly.


Doug Schaefer <DSchaefer@xxxxxxx>
Sent by: cdt-dev-bounces@xxxxxxxxxxx

09/14/2006 11:27 AM

Please respond to
"CDT General developers list." <cdt-dev@xxxxxxxxxxx>

"CDT General developers list." <cdt-dev@xxxxxxxxxxx>
RE: [cdt-dev] Existing Binding cannot be resolved

Hi, Johannes. Your best bet would be to raise a bug report on this.

Doug Schaefer
QNX Software Systems
Eclipse CDT Project Lead

-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
Behalf Of Johannes Wust
Sent: Thursday, September 14, 2006 12:46 AM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] Existing Binding cannot be resolved

Hi CDT developers,

I already posted this issue two weeks ago on the newsgroup, but didn't
get a response. I think it might be interesting for you, assuming that
this is not already a known issue:

I encountered a problem when building the AST. Several Bindings of
Methodnames could not be resolved, but the Bindings where actually

An example was the method substr of basic_string from libstdc++;

resolveBinding() returns a ProblemBinding
resolvePrefix() returns an Array containg one Binding - the Binding of
the method substr;

So I had a look at the code of CDT to find out how Bindings are
resolved. I started at CPPVisitor.createBinding(IASTName name). This
Method calls then CPPSemantics.resolveBinding(IASTName name).

In resolveBinding(IASTName name), the lookup of data and context info
works fine  and resolveAmbiguities( CPPSemantics.LookupData data,
IASTName name ) gets called.

In resolveAmbiguities, everything seems to be OK, and at the end
CPPSematics.resolveFunction( CPPSemantics.LookupData data, IBinding[]
fns ) gets called. The parameter fns contains only one Binding - the
correct Binding.

What basically happens in resolveFunction is that the correct Binding
gets refused as it gets negative ranks for the cost and the "best"
Binding null gets returned. As far as I understood the code, substr gets
negative ranks as the Parameter do not match. substr has parameters of
type size_type, which is unknown to the comparison logic and the actual
method call has integer values as parameters.

I did not really get why the code tries to find a better Binding when
there exists only one Binding. Is there a reason? Or is it likely that
wrong Bindings are found and null is just a better return value than sth

Is this a known issue and does anybody know a better solution than just
picking the Binding returned by resolvePrefix, check if the name and
number of arguments is the same and take that as a good guess.

Thanks for paying attention to this issue,


**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
for the use of the addressee(s). If you are not the intended recipient,
please notify the sender by e-mail and delete the original message. Further,
you are not to copy, disclose, or distribute this e-mail or its contents to
any other person and any such actions are unlawful. This e-mail may contain
viruses. Infosys has taken every reasonable precaution to minimize this
risk, but is not liable for any damage you may sustain as a result of any
virus in this e-mail. You should carry out your own virus checks before
opening the e-mail or attachment. Infosys reserves the right to monitor and
review the content of all messages sent to or from this e-mail address.
Messages sent to or from this e-mail address may be stored on the Infosys
e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
cdt-dev mailing list
cdt-dev mailing list

Back to the top