Getting "wrong" ObjCMethodDecl-reference from ObjCMessageExpr


while playing around with libClang and trying to extract some
statistics of objective-c-code, I encountered some strange behavior on
ObjCMessageExpr-instances have a getMethodDecl-method, which I'm
expecting to return the _exact_ ObjCMethodDecl-instance if clang is
able to deduce it - or null, if clang has not the ability to do so.
Thus, sending a message to an id-variable should always return null.
Instead, I'm getting a ObjCMethodDecl-instance bound to the first
matching method-declaration within the code. Is this the expected

Side information:
Using clang r156161
My code loads an ast-file and runs a RecursiveASTVisitor on it
The testcode for this case (gmail/Safari won't let me attach files, sorry)
// test: sending a message to a id-variable with two candidates for
// expected: ObjCMessageExpr->getMethodDecl should return null, as
clang can't deduce the right ObjCMethodDecl for id-variables
// result: ObjCMessageExpr->getMethodDecl returns a methoddecl
belonging to Hotzi::murgel
@interface Hotzi

@implementation Hotzi
-(void)murgel {}

@interface Mugi

@implementation Mugi

-(void)bonk:(id)x {
  [x murgel];

-(void)murgel {}


The compiler never has the ability to deduce the exact method that a
message send goes to, because it's supported behavior to do things
like replace methods at runtime or patch the class pointer or whatever.

ObjCMessageExpr points to the method that the message send was
type-checked against. The specified behavior in the case of a message
send to 'id' is to type-check against the first method with that selector
that was declared in the file. Finding a method to type-check against
is important because many, many methods do not return a type
compatible with 'id'. Using the first method is also important because
(IIRC) Cocoa manages to declare two methods with incompatible
return types using the 'length' selector, and it's critical that we silently
pick the one from NSString.


Sounds plausible, thank you!